Systems and methods for push notification management

ABSTRACT

The present disclosure relates to methods and systems for delivering and presenting notifications at a consumer device. The method includes receiving, by a notification manager, from a client device, a notification to be delivered to an application executing on a consumer device. The method also includes holding, by the notification manager, the notification in a notification queue. The method further includes identifying, by the notification manager, a consumer notification policy of the consumer device applicable to the notification, the consumer notification policy specifying one or more conditions for presenting the notification at the consumer device. The method further includes releasing, by the notification manager, from the notification queue, the notification for presentation at the consumer device upon determining that the conditions of the consumer notification policy have been met.

RELATED APPLICATIONS

This application claims the benefit of and priority to U.S. ProvisionalApplication No. 61/897,553, entitled “SYSTEMS AND METHODS FOR DELIVERINGMESSAGES VIA SMPP BRIDGE FOR MULTIPLE DELIVERY CHANNELS” and filed onOct. 30, 2013, and to U.S. Provisional Application No. 61/904,774,entitled “SYSTEMS AND METHODS FOR PUSH NOTIFICATION MANAGEMENT” andfiled on Nov. 15, 2013, both of which are incorporated herein byreference in their entirety for all purposes.

FIELD OF THE DISCLOSURE

The present application relates generally to managing notifications sentto one or more computing devices and, more particularly, to systems andmethods for managing push notifications.

BACKGROUND

For various reasons, many mobile application providers are unable tosend push notifications to mobile applications installed on consumerdevices. However, these mobile application providers desire tocommunicate with consumers that have installed mobile applications ofthe mobile applications providers on their respective consumer devices.Such mobile application providers that desire to send push notificationsto consumers face many challenges. For example, for a mobile applicationprovider to send push notifications to the mobile applications installedon respective consumer devices, the mobile application provider may needto create a new mobile application that allows for push notifications.The consumers will then have to install the new updated mobileapplication after which the consumers can receive push notifications viathe mobile application. Moreover, the mobile application provider willneed to set up a push notification system through which the mobileapplication provider can send push notifications. These challenges canbe expensive to undertake and time consuming and as such, are notfeasible for many mobile application providers.

SUMMARY

Various embodiments disclosed herein are directed to methods and systemsfor delivering messages received via the Short Message Peer-to-Peer(SMPP) protocol over a plurality of delivery channels are provided.Through these various embodiments, a client can be configured to sendmessages over an SMPP bridge, which can be processed and delivered toone or more consumers associated with the client over any of a pluralityof SMPP-type and non-SMPP type delivery channels. Examples of thevarious delivery channels include SMS, push notifications, email,instant messaging, and social media application messaging, amongstothers. In this way, a client can use the SMPP protocol to send messagesusing both SMPP-based and non-SMPP based delivery channels.

A message delivery system acting as an intermediary between one or moreclients and one or more consumers can be configured to establish aconnection with the client via an SMPP protocol. In someimplementations, the client may be a company, business or any otherentity that may wish to send messages to one or more recipients, such asconsumers. The consumers may be current, past or future customers,users, members or subscribers of the client or services provided by theclient. The message delivery system can receive, from the client via theSMPP protocol, an SMPP request to deliver a message to at least one of aplurality of consumers. The request can include the message to bedelivered and identify a delivery policy according to which the messageis to be delivered to one or more consumers. The delivery policy caninclude one or more rules for delivering the message, including but notlimited to identifying one or more target delivery channels throughwhich to deliver the message, identifying a time at which to deliver themessage, identifying one or more conditions for delivering the message,for example, a condition requiring that the consumer device be locatedwithin a particular geographic region, amongst other rules.

A message delivery system acting as an intermediary between one or moreclients and one or more consumers can be configured to establish aconnection with the client via an SMPP protocol. The message deliverysystem can receive, from the client via the SMPP protocol, an SMPPrequest to deliver a message to at least one of a plurality ofconsumers. The request can include the message to be delivered andidentify a delivery policy according to which the message is to bedelivered to one or more consumers. The delivery policy can include oneor more rules for delivering the message, including but not limited toidentifying one or more target delivery channels through which todeliver the message, identifying a time at which to deliver the message,identifying one or more conditions for delivering the message, forexample, a condition requiring that the consumer device be locatedwithin a particular geographic region, amongst other rules.

In some implementations, the message delivery system can inspect therequest to identify the delivery policy. The message delivery system canthen process the request and based on the target delivery channelthrough which to deliver the message identified in the delivery policy,transmit the message included within the request to the consumer inaccordance with the delivery policy. In some implementations, thedelivery channel can be a push notification delivery channel throughwhich the message is delivered to a consumer device as a pushnotification via an application operating on the consumer device. Insome implementations, the delivery channel can be a Short MessageService (SMS) delivery channel through which the message is delivered toa consumer device as an SMS message. In some implementations, thedelivery channel can be an email delivery channel through which themessage is delivered to a consumer device as an email message via a mailapplication. In some implementations, the delivery channel can be aninstant messaging channel through which the message is delivered to aconsumer device as an instant message via an instant messagingapplication.

In some implementations, the message delivery system can be configuredto establish an SMPP connection with a client agent operating on aclient, over which the message delivery system and the client cancommunicate. The client agent can be configured to generate an SMPPrequest that includes the message to be delivered as well as thedelivery policy according to which the message is to be delivered. Inaddition, the message delivery system can be configured to communicatewith an application operating on the consumer device through which themessage delivery system can send push notifications to the consumerdevice. In some implementations, the message delivery system canestablish a secure connection with the application and deliver pushnotifications through the secure connection. In some otherimplementations, the message delivery system can send push notificationsthrough a third-party push notification service that is configured tosend the push notification to the application operating on the consumerdevice. In some such implementations, the message delivery system cansend push notifications to social network based applications, forexample, Facebook, Twitter, amongst others. In some implementations, themessage delivery system can deliver the messages as email messages,instant messages, social network-based messages or posts, amongstothers. In some implementations, the message delivery system can deliverthe messages as SMS messages. In some implementations, the messagedelivery system can deliver the messages using more than one deliverychannel. In this way, the message delivery system can, for example,deliver an SMS message, an instant message and an email message all inresponse to a single SMPP request from the client.

In one aspect, the present disclosure is directed to a method fordelivering messages received via a short message peer-to-peer (SMPP)protocol over one of a plurality of delivery channels. The methodincludes establishing, by a message deliverer configured on a deviceintermediary between a client device and a plurality of consumerdevices, a short message peer-to-peer (SMPP) connection with the clientdevice based on SMPP protocol, the SMPP connection for communicatingshort message service (SMS) messages. The method also includesreceiving, by the message deliverer, from the client device over theSMPP connection, a first request, via the SMPP protocol, to deliver amessage to at least one consumer device of the plurality of consumerdevices. The first request can include the message and a delivery policyspecifying one or more non-SMS delivery channels through which todeliver the message. The method further includes identifying, by themessage deliverer, from the delivery policy in the first request, theone or more non-SMS delivery channels. The method further includestransmitting, by the message deliverer, for the one or more non-SMSdelivery channels, a second request to deliver the message via the oneor more non-SMS delivery channels to the at least one consumer device.

In some embodiments, the method includes transmitting, by the messagedeliverer, for a first non-SMS delivery channel, a corresponding secondrequest to a first entity configured to transmit the message to theconsumer device via the first non-SMS delivery channel. In thoseembodiments, the method can also include transmitting, by the messagedeliverer, for a second non-SMS delivery channel, another correspondingsecond request to a second entity configured to transmit the message tothe consumer device via the second non-SMS delivery channel.

In some embodiments, one of the non-SMS delivery channels includes oneof a) a push notification delivery channel through which the message isdelivered to a consumer device as a push notification via an applicationoperating on the consumer device, or b) an instant messaging channelthrough which the message is delivered to a consumer device as aninstant message via an instant messaging application.

In some embodiments, the method includes establishing the SMPPconnection with a client agent operating on the client device.

In some embodiments, the at least one consumer device includes anapplication operating on the recipient consumer device. In thoseembodiments, the method includes transmitting, by the message deliverer,the message towards the consumer device such that a notificationdelivery application executing on the consumer device receives themessage and responsive to a consumer delivery policy, presents thenotification on the consumer device as one of a push notification or aninstant message.

In some embodiments, the method further includes inspecting a header ofthe first request, identifying fields of the header of the firstrequest, and determining, from values of the identified fields, thedelivery policy according to which to deliver the message.

In some embodiments, the delivery policy specifies a time at which todeliver the message, or a triggering condition, which when triggered,causes the message to be delivered. In some embodiments, the deliverypolicy specifies an application executing on the mobile device via whichto present the message as a notification on the consumer device. In someembodiments, the delivery policy identifies one or more of a) one ormore consumer devices to which the message is to be delivered, b) one ormore non-SMS delivery channels according to which the message is to bedelivered, or c) a time at which the message is to be delivered.

In some embodiments, the method includes transmitting the second requestto a third-party push notification service configured to transmit themessage included in the second request to the consumer device forpresentation via an application executing on the client device. Theapplication can be specific to the client device.

In one aspect, the present disclosure is directed to a system fordelivering messages received via a short message peer-to-peer (SMPP)protocol over one of a plurality of delivery channels. The systemincludes a message deliverer executing on a device intermediary betweena client device and a plurality of consumer devices. The messagedeliverer includes a memory having processor executable instructionsstored thereon and a processor configured to execute the processorexecutable instructions stored on the memory. The processor isconfigured to establish a short message peer-to-peer (SMPP) connectionwith the client device based on SMPP protocol, the SMPP connection forcommunicating short message service (SMS) messages. The processor isalso configured to receive, from the client device over the SMPPconnection, a first request, via the SMPP protocol, to deliver a messageto at least one consumer device of the plurality of consumer devices.The first request can include the message and a delivery policyspecifying one or more non-SMS delivery channels through which todeliver the message. The processor is further configured to identify,from the delivery policy in the first request, the one or more non-SMSdelivery channels. The processor is further configured to transmit, forthe one or more non-SMS delivery channels, a second request to deliverthe message via the one or more non-SMS delivery channels to the atleast one consumer device.

In some embodiments of the system, the processor is configured totransmit, for a first non-SMS delivery channel, a corresponding secondrequest to a first entity configured to transmit the message to theconsumer device via the first non-SMS delivery channel. In thoseembodiments, the processor is further configured to transmit, for asecond non-SMS delivery channel, another corresponding second request toa second entity configured to transmit the message to the consumerdevice via the second non-SMS delivery channel.

In some embodiments of the system, the one of the non-SMS deliverychannels includes one of a) a push notification delivery channel throughwhich the message is delivered to a consumer device as a pushnotification via an application operating on the consumer device, or b)an instant messaging channel through which the message is delivered to aconsumer device as an instant message via an instant messagingapplication.

In some embodiments of the system, the processor is configured toestablish the SMPP connection with a client agent operating on theclient device.

In some embodiments of the system, the at least one consumer deviceincludes an application operating on the recipient consumer device. Inthose embodiments, the processor is configured to transmit, by themessage deliverer, the message towards the consumer device such that anotification delivery application executing on the consumer devicereceives the message and responsive to a consumer delivery policy,presents the notification on the consumer device as one of a pushnotification or an instant message.

In some embodiments of the system, the processor is further configuredto inspect a header of the first request, identify fields of the headerof the first request, and determine, from values of the identifiedfields, the delivery policy according to which to deliver the message.

In some embodiments of the system, the delivery policy specifies a timeat which to deliver the message, or a triggering condition, which whentriggered, causes the message to be delivered. In some embodiments ofthe system, the delivery policy specifies an application executing onthe mobile device via which to present the message as a notification onthe consumer device. In some embodiments of the system, the deliverypolicy identifies one or more of a) one or more consumer devices towhich the message is to be delivered, b) one or more non-SMS deliverychannels according to which the message is to be delivered, or c) a timeat which the message is to be delivered.

In some embodiments of the system, the processor is configured totransmit the second request to a third-party push notification serviceconfigured to transmit the message included in the second request to theconsumer device for presentation via an application executing on theclient device, the application specific to the client device

According to one aspect, a system for delivering messages received viathe SMPP protocol over one of a plurality of delivery channels isprovided. A message delivery system acting as an intermediary between aclient and a plurality of consumers can be configured to establish aconnection with the client via an SMPP protocol. The message deliverysystem can receive, from the client via the SMPP protocol, a request todeliver a message to at least one of a plurality of consumers. Therequest can identify a delivery policy according to which the message isto be delivered to the consumer. In some implementations, the messagedelivery system can inspect the request to identify the delivery policyaccording to which the message is to be delivered to the consumer. Themessage delivery system can then process the request and transmit themessage included within the request to the consumer in accordance withthe delivery policy. In some implementations, the delivery policy canidentify a delivery channel over which the message is to be delivered.

Various embodiments disclosed herein are directed to methods and systemsfor managing and delivering communications to one or more consumerdevices via an application provider proxy, such as managing pushnotifications sent to applications on a consumer's mobile device. Theapplication provider proxy can act as an intermediary to one or moreclients and one or more consumer devices. The application provider proxycan be configured to manage and deliver push notifications to one ormore consumer devices. In some implementations, the application providerproxy can be configured to communicate with a consumer device via anotification delivery application that can be installed on the consumerdevice. The application provider proxy can be configured to send pushnotifications to the notification delivery application. Moreover, theapplication provider proxy can be configured to exchange communicationswith the notification delivery application through push and pullrequests issued by both the application provider proxy and thenotification delivery application.

Many clients that wish to communicate with consumers via the consumer'smobile devices either do so by sending SMS messages, push notificationsto mobile applications dedicated to the clients that are installed onthe consumer devices, or through other forms of communication, such asemail. Clients that either have mobile applications that are unable toreceive push notifications or do not have mobile applications are unableto communicate with their consumers via push notifications. The presentdisclosure enables such clients to establish communications withconsumers via their consumer devices using push notifications. In someimplementations, the application provider proxy serves as anintermediary between such clients and their consumers and can send pushnotifications to notification delivery applications installed on theconsumers' devices. These push notifications can be generated inresponse to receiving requests to send communications from such clients.Moreover, these push notifications can trigger an exchange ofinformation between the application provider proxy and the consumerdevices such that the consumer devices can take additional actions oncethe consumer accesses the push notification received on the consumer'sdevice. These actions can include launching one or more third-partyapplications or services, launching a mobile application of the client,launching a browser and directing the consumer to a particular webpage,amongst others.

The application provider proxy can be configured to communicate with aclient of the application provider proxy (for example, a mobileapplication provider providing mobile applications that are unable toreceive push notifications) that wishes to send a push notification orother communication to one or more consumer devices. The client can senda request to the application provider proxy to send a push notificationto the consumer device on behalf of the client. For example, the clientcan request to notify the consumer that their account balance has fallenbelow a threshold amount by sending a push notification to the consumerdevice and directing the consumer device to launch a mobile applicationof the client showing the current account balance upon the consumeraccessing the push notification. The application provider proxy canprocess the request and send a push notification to the notificationdelivery application installed on the consumer device. Upon receivingthe push notification, the notification delivery application can presentthe notification for display to the consumer. The consumer can accessthe push notification delivered through the notification deliveryapplication. The notification delivery application can identify that theconsumer has accessed the push notification and can process the pushnotification by performing a pull request for data from the applicationprovider proxy. The application provider proxy in turn can identify theconsumer device from which the pull request is received and sendadditional data or instructions to the notification delivery applicationof the identified consumer device. These instructions can be based onthe request received from the client. In this example, the applicationprovider proxy can identify the consumer and based on the requestreceived from the client, send instructions to the notification deliveryapplication to launch the client's mobile application and show theconsumer the consumer's current account balance via the client's mobileapplication. These instructions can cause the notification deliveryapplication to perform one or more additional actions specified in theinstructions. In the example described herein, the notification deliveryapplication can cause the consumer device to launch the client's mobileapplication and show the consumer the consumer's current accountbalance. Other examples of actions that the notification deliveryapplication can cause the consumer device to perform include launching athird-party application or service, opening a browser on the consumerdevice and directing the browser to a particular address provided by themobile application provider, amongst others.

In some implementations, the application provider proxy can beconfigured to deliver push notifications to a consumer device accordingto a notification delivery policy of the consumer device. Thenotification delivery policy of the consumer device can include one ormore rules indicating the manner in which notifications can be deliveredto the consumer device. The consumer can specify the rules of thenotification delivery policy. Examples of the rules can includedelivering notifications only within certain times, deliveringnotifications when the consumer device is identified to be within aparticular geographic area or region, amongst others.

The application provider proxy can communicate with the notificationdelivery application installed on one or more consumer devices via pushnotifications. The notification delivery application can be configuredto receive the push notifications and take one or more actionsresponsive to the push notifications. In some implementations, thenotification delivery application can be configured to present thenotifications at the consumer device in accordance with a consumernotification policy. The consumer notification policy can include one ormore rules specifying the manner in which notifications can bepresented. The application can be configured to take one or more actionsresponsive to presenting the notification. In some implementations, theapplication can be configured to take one or more actions responsive topresenting the notification at the consumer device and receiving aresponse from a consumer of the consumer device.

The message delivery application installed on the consumer device canreceive a notification from the application provider proxy and executeone or more instructions responsive to receiving the notification. Insome implementations, the message delivery application can be configuredto perform one or more actions in response to a user of the consumerdevice taking an action in response to the notification received by theconsumer device. These actions can correspond to opening a web browserand accessing a web page, opening a third-party application, amongstothers.

In some implementations, the application provider proxy may delivernotifications in accordance with a consumer notification policy. Theconsumer notification policy can include one or more rules identifying adelivery channel through which to deliver the notification, conditionsin which to hold the notification and conditions in which to release thenotification for presentation, the manner in which the notification isto be presented on the consumer device, amongst others.

In one aspect, the present disclosure is directed to a method fordelivering and presenting notifications at a consumer device. The methodincludes receiving, by a notification manager, from a client device, anotification to be delivered to an application executing on a consumerdevice. The method also includes holding, by the notification manager,the notification in a notification queue. The method further includesidentifying, by the notification manager, a consumer notification policyof the consumer device applicable to the notification, the consumernotification policy specifying one or more conditions for presenting thenotification at the consumer device. The method further includesreleasing, by the notification manager, from the notification queue, thenotification for presentation at the consumer device upon determiningthat the conditions of the consumer notification policy have been met.

In some embodiments of the method, the notification manager isconfigured on a device intermediary to the client device and a pluralityof consumer devices including the consumer device. In some embodiments,the notification manager is configured on the consumer device.

In some embodiments, the method further includes determining that theconditions of the consumer notification policy have been met. In suchembodiments, the method may include identifying one or more conditionsof the consumer notification policy, and determining, for at least oneof the conditions, that the condition is based on a triggering event.Also in such embodiments, the method may include receiving, by thenotification manager, information associated with the triggering event,and determining, from the received information, that the triggeringevent has occurred.

In some embodiments, the method includes determining a consumernotification policy based on the type of notification to be delivered.In some embodiments of the method, the consumer notification policyincludes rules identifying a) a delivery channel through which todeliver the notification, b) one or more conditions in which to hold thenotification, c) one or more conditions in which to release thenotification for presentation, or d) the manner in which thenotification is to be presented on the consumer device. In someembodiments of the method, one or more of the conditions are based on alocation of the consumer device, activity performed on the consumerdevice, or a time associated with the consumer device.

In some embodiments, the method includes receiving third-party data froma third-party source corresponding to the one or more conditions of theconsumer notification policy, and determining, based on the receivedthird-party data, that conditions of the consumer notification policyhave been met.

In some embodiments, the method includes storing the notification in anotification database along with a record associated with thenotification.

In some embodiments, the method includes delivering, by the notificationmanager, the notification to a notification delivery applicationexecuting on the consumer device, where the notification deliveryapplication presents the notification in accordance with notificationpresentation rules specified in the consumer notification policy.

In one aspect, the present disclosure is directed to a system fordelivering and presenting notifications at a consumer device. The systemincludes a delivery manager intermediary to a client device and aconsumer device. The delivery manager may be configured to receive, froma client device, a notification to be delivered to an applicationexecuting on a consumer device and hold the notification in anotification queue. The delivery manager may be also configured toidentify a consumer notification policy of the consumer deviceapplicable to the notification, the consumer notification policyspecifying one or more conditions for presenting the notification at theconsumer device. The delivery manager may be further configured torelease, from the notification queue, the notification for presentationat the consumer device upon determining that the conditions of theconsumer notification policy have been met.

In some embodiments of the system, the notification manager isconfigured on a device intermediary to the client device and a pluralityof consumer devices including the consumer device. In some embodimentsof the system, the notification manager is configured on the consumerdevice.

In some embodiments of the system, the delivery manager is furtherconfigured to determine that the conditions of the consumer notificationpolicy have been met. In such embodiments, the delivery manager isfurther configured to identify one or more conditions of the consumernotification policy, and determine, for at least one of the conditions,that the condition is based on a triggering event. Also in suchembodiments, the delivery manager is further configured to receiveinformation associated with the triggering event, and determine, fromthe received information, that the triggering event has occurred.

In some embodiments of the system, the delivery manager is furtherconfigured to determine a consumer notification policy based on the typeof notification to be delivered.

In some embodiments of the system, the consumer notification policyincludes rules identifying a) a delivery channel through which todeliver the notification, b) one or more conditions in which to hold thenotification, c) one or more conditions in which to release thenotification for presentation, or d) the manner in which thenotification is to be presented on the consumer device. In someembodiments of the system, one or more of the conditions are based on alocation of the consumer device, activity performed on the consumerdevice, or a time associated with the consumer device.

In some embodiments of the system, the delivery manager is configured toreceive third-party data from a third-party source corresponding to oneor more conditions of the consumer notification policy. The deliverymanager is further configured to determine, based on the receivedthird-party data, that conditions of the consumer notification policyhave been met.

In some embodiments of the system, the delivery manager is configured tostore the notification in a notification database along with a recordassociated with the notification.

In some embodiments of the system, the delivery manager is furtherconfigured to deliver the notification to a notification deliveryapplication executing on the consumer device, where the notificationdelivery application presents the notification in accordance withnotification presentation rules specified in the consumer notificationpolicy.

According to one aspect, a method for delivering and presentingnotifications via an application provider proxy includes identifying anoccurrence of an event for which a notification is to be delivered to aconsumer device. The method also includes identifying a consumernotification policy associated with the consumer device applicable tothe notification to be delivered and holding the notification untilconditions of the consumer notification policy have been met. The methodalso includes releasing the notification for presentation at theconsumer device upon determining that the rules of the consumernotification policy have been met.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram depicting an embodiment of a networkenvironment comprising local devices in communication with remotedevices.

FIGS. 1B-1D are block diagrams depicting embodiments of computers usefulin connection with the methods and systems described herein.

FIG. 2A is a block diagram depicting an environment comprising acommunication technology platform useful in connection with the methodsand systems described herein.

FIG. 2B depicts a process flow associated with the communicationtechnology platform.

FIG. 2C is a block diagram depicting an embodiment of an aggregatorimplementing the communication technology platform.

FIG. 3A is a block diagram illustrating a computer networked environmentfor delivering messages received via the SMPP protocol over one of aplurality of delivery channels.

FIG. 3B is a block diagram illustrating a flow of a method fordelivering messages received via the SMPP protocol over one of aplurality of delivery channels.

FIG. 4A is a block diagram illustrating a computer networked environmentfor delivering communications via an application provider proxy.

FIG. 4B is a block diagram illustrating a flow of a method fordelivering communications via an application provider proxy.

DETAILED DESCRIPTION

For purposes of reading the description of the various embodimentsbelow, the following descriptions of the sections of the specificationand their respective contents may be helpful:

Section A describes a network environment and computing environmentwhich may be useful for practicing embodiments described herein.

Section B describes a communication platform which may be useful forpracticing embodiments described herein.

Section C describes embodiments of systems and methods for deliveringmessages received via the SMPP protocol over one of a plurality ofdelivery channels.

Section D describes embodiments of systems and methods for deliveringcommunications via an application provider proxy.

A. Computing and Network Environment

Prior to discussing specific embodiments of the present solution, it maybe helpful to describe aspects of the operating environment as well asassociated system components (e.g., hardware elements) in connectionwith the methods and systems described herein. Referring to FIG. 1A, anembodiment of a network environment is depicted. In brief overview, thenetwork environment includes one or more clients 102 a-102 n (alsogenerally referred to as local machine(s) 102, client(s) 102, clientnode(s) 102, client machine(s) 102, client computer(s) 102, clientdevice(s) 102, endpoint(s) 102, or endpoint node(s) 102) incommunication with one or more servers 106 a-106 n (also generallyreferred to as server(s) 106, node 106, or remote machine(s) 106) viaone or more networks 104. In some embodiments, a client 102 has thecapacity to function as both a client node seeking access to resourcesprovided by a server and as a server providing access to hostedresources for other clients 102 a-102 n.

Although FIG. 1A shows a network 104 between the clients 102 and theservers 106, the clients 102 and the servers 106 may be on the samenetwork 104. In some embodiments, there are multiple networks 104between the clients 102 and the servers 106. In one of theseembodiments, a network 104′ (not shown) may be a private network and anetwork 104 may be a public network. In another of these embodiments, anetwork 104 may be a private network and a network 104′ a publicnetwork. In still another of these embodiments, networks 104 and 104′may both be private networks.

The network 104 may be connected via wired or wireless links. Wiredlinks may include Digital Subscriber Line (DSL), coaxial cable lines, oroptical fiber lines. The wireless links may include BLUETOOTH, Wi-Fi,Worldwide Interoperability for Microwave Access (WiMAX), an infraredchannel or satellite band. The wireless links may also include anycellular network standards used to communicate among mobile devices,including standards that qualify as 1G, 2G, 3G, or 4G. The networkstandards may qualify as one or more generation of mobiletelecommunication standards by fulfilling a specification or standardssuch as the specifications maintained by International TelecommunicationUnion. The 3G standards, for example, may correspond to theInternational Mobile Telecommunications-2000 (IMT-2000) specification,and the 4G standards may correspond to the International MobileTelecommunications Advanced (IMT-Advanced) specification. Examples ofcellular network standards include AMPS, GSM, GPRS, UMTS, LTE, LTEAdvanced, Mobile WiMAX, and WiMAX-Advanced. Cellular network standardsmay use various channel access methods e.g. FDMA, TDMA, CDMA, or SDMA.In some embodiments, different types of data may be transmitted viadifferent links and standards. In other embodiments, the same types ofdata may be transmitted via different links and standards.

The network 104 may be any type and/or form of network. The geographicalscope of the network 104 may vary widely and the network 104 can be abody area network (BAN), a personal area network (PAN), a local-areanetwork (LAN), e.g. Intranet, a metropolitan area network (MAN), a widearea network (WAN), or the Internet. The topology of the network 104 maybe of any form and may include, e.g., any of the following:point-to-point, bus, star, ring, mesh, or tree. The network 104 may bean overlay network which is virtual and sits on top of one or morelayers of other networks 104′. The network 104 may be of any suchnetwork topology as known to those ordinarily skilled in the art capableof supporting the operations described herein. The network 104 mayutilize different techniques and layers or stacks of protocols,including, e.g., the Ethernet protocol, the internet protocol suite(TCP/IP), the ATM (Asynchronous Transfer Mode) technique, the SONET(Synchronous Optical Networking) protocol, or the SDH (SynchronousDigital Hierarchy) protocol. The TCP/IP internet protocol suite mayinclude application layer, transport layer, internet layer (including,e.g., IPv6), or the link layer. The network 104 may be a type of abroadcast network, a telecommunications network, a data communicationnetwork, or a computer network.

In some embodiments, the system may include multiple, logically-groupedservers 106. In one of these embodiments, the logical group of serversmay be referred to as a server farm 38 or a machine farm 38. In anotherof these embodiments, the servers 106 may be geographically dispersed.In other embodiments, a machine farm 38 may be administered as a singleentity. In still other embodiments, the machine farm 38 includes aplurality of machine farms 38. The servers 106 within each machine farm38 can be heterogeneous—one or more of the servers 106 or machines 106can operate according to one type of operating system platform (e.g.,WINDOWS NT, manufactured by Microsoft Corp. of Redmond, Wash.), whileone or more of the other servers 106 can operate on according to anothertype of operating system platform (e.g., Unix, Linux, or Mac OS X).

In one embodiment, servers 106 in the machine farm 38 may be stored inhigh-density rack systems, along with associated storage systems, andlocated in an enterprise data center. In this embodiment, consolidatingthe servers 106 in this way may improve system manageability, datasecurity, the physical security of the system, and system performance bylocating servers 106 and high performance storage systems on localizedhigh performance networks. Centralizing the servers 106 and storagesystems and coupling them with advanced system management tools allowsmore efficient use of server resources.

The servers 106 of each machine farm 38 do not need to be physicallyproximate to another server 106 in the same machine farm 38. Thus, thegroup of servers 106 logically grouped as a machine farm 38 may beinterconnected using a wide-area network (WAN) connection or ametropolitan-area network (MAN) connection. For example, a machine farm38 may include servers 106 physically located in different continents ordifferent regions of a continent, country, state, city, campus, or room.Data transmission speeds between servers 106 in the machine farm 38 canbe increased if the servers 106 are connected using a local-area network(LAN) connection or some form of direct connection. Additionally, aheterogeneous machine farm 38 may include one or more servers 106operating according to a type of operating system, while one or moreother servers 106 execute one or more types of hypervisors rather thanoperating systems. In these embodiments, hypervisors may be used toemulate virtual hardware, partition physical hardware, virtualizephysical hardware, and execute virtual machines that provide access tocomputing environments, allowing multiple operating systems to runconcurrently on a host computer. Native hypervisors may run directly onthe host computer. Hypervisors may include VMware ESX/ESXi, manufacturedby VMWare, Inc., of Palo Alto, Calif.; the Xen hypervisor, an opensource product whose development is overseen by Citrix Systems, Inc.;the HYPER-V hypervisors provided by Microsoft or others. Hostedhypervisors may run within an operating system on a second softwarelevel. Examples of hosted hypervisors may include VMware Workstation andVIRTUALBOX.

Management of the machine farm 38 may be de-centralized. For example,one or more servers 106 may comprise components, subsystems and modulesto support one or more management services for the machine farm 38. Inone of these embodiments, one or more servers 106 provide functionalityfor management of dynamic data, including techniques for handlingfailover, data replication, and increasing the robustness of the machinefarm 38. Each server 106 may communicate with a persistent store and, insome embodiments, with a dynamic store.

Server 106 may be a file server, application server, web server, proxyserver, appliance, network appliance, gateway, gateway server,virtualization server, deployment server, SSL VPN server, or firewall.In one embodiment, the server 106 may be referred to as a remote machineor a node. In another embodiment, a plurality of nodes 290 may be in thepath between any two communicating servers.

Referring to FIG. 1B, a cloud computing environment is depicted. A cloudcomputing environment may provide client 102 with one or more resourcesprovided by a network environment. The cloud computing environment mayinclude one or more clients 102 a-102 n, in communication with the cloud108 over one or more networks 104. Clients 102 may include, e.g., thickclients, thin clients, and zero clients. A thick client may provide atleast some functionality even when disconnected from the cloud 108 orservers 106. A thin client or a zero client may depend on the connectionto the cloud 108 or server 106 to provide functionality. A zero clientmay depend on the cloud 108 or other networks 104 or servers 106 toretrieve operating system data for the client device. The cloud 108 mayinclude back end platforms, e.g., servers 106, storage, server farms ordata centers.

The cloud 108 may be public, private, or hybrid. Public clouds mayinclude public servers 106 that are maintained by third parties to theclients 102 or the owners of the clients. The servers 106 may be locatedoff-site in remote geographical locations as disclosed above orotherwise. Public clouds may be connected to the servers 106 over apublic network. Private clouds may include private servers 106 that arephysically maintained by clients 102 or owners of clients. Privateclouds may be connected to the servers 106 over a private network 104.Hybrid clouds 108 may include both the private and public networks 104and servers 106.

The cloud 108 may also include a cloud based delivery, e.g. Software asa Service (SaaS) 110, Platform as a Service (PaaS) 112, andInfrastructure as a Service (IaaS) 114. IaaS may refer to a user rentingthe use of infrastructure resources that are needed during a specifiedtime period. IaaS providers may offer storage, networking, servers orvirtualization resources from large pools, allowing the users to quicklyscale up by accessing more resources as needed. Examples of IaaS includeAMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Wash.,RACKSPACE CLOUD provided by Rackspace US, Inc., of San Antonio, Tex.,Google Compute Engine provided by Google Inc. of Mountain View, Calif.,or RIGHTSCALE provided by RightScale, Inc., of Santa Barbara, Calif.PaaS providers may offer functionality provided by IaaS, including,e.g., storage, networking, servers or virtualization, as well asadditional resources such as, e.g., the operating system, middleware, orruntime resources. Examples of PaaS include WINDOWS AZURE provided byMicrosoft Corporation of Redmond, Wash., Google App Engine provided byGoogle Inc., and HEROKU provided by Heroku, Inc. of San Francisco,Calif. SaaS providers may offer the resources that PaaS provides,including storage, networking, servers, virtualization, operatingsystem, middleware, or runtime resources. In some embodiments, SaaSproviders may offer additional resources including, e.g., data andapplication resources. Examples of SaaS include GOOGLE APPS provided byGoogle Inc., SALESFORCE provided by Salesforce.com Inc. of SanFrancisco, Calif., or OFFICE 365 provided by Microsoft Corporation.Examples of SaaS may also include data storage providers, e.g. DROPBOXprovided by Dropbox, Inc. of San Francisco, Calif., Microsoft SKYDRIVEprovided by Microsoft Corporation, Google Drive provided by Google Inc.,or Apple ICLOUD provided by Apple Inc. of Cupertino, Calif.

Clients 102 may access IaaS resources with one or more IaaS standards,including, e.g., Amazon Elastic Compute Cloud (EC2), Open CloudComputing Interface (OCCI), Cloud Infrastructure Management Interface(CIMI), or OpenStack standards. Some IaaS standards may allow clientsaccess to resources over HTTP, and may use Representational StateTransfer (REST) protocol or Simple Object Access Protocol (SOAP).Clients 102 may access PaaS resources with different PaaS interfaces.Some PaaS interfaces use HTTP packages, standard Java APIs, JavaMailAPI, Java Data Objects (JDO), Java Persistence API (JPA), Python APIs,web integration APIs for different programming languages including,e.g., Rack for Ruby, WSGI for Python, or PSGI for Perl, or other APIsthat may be built on REST, HTTP, XML, or other protocols. Clients 102may access SaaS resources through the use of web-based user interfaces,provided by a web browser (e.g. GOOGLE CHROME, Microsoft INTERNETEXPLORER, or Mozilla Firefox provided by Mozilla Foundation of MountainView, Calif.). Clients 102 may also access SaaS resources throughsmartphone or tablet applications, including, e.g., Salesforce SalesCloud, or Google Drive app. Clients 102 may also access SaaS resourcesthrough the client operating system, including, e.g., Windows filesystem for DROPBOX.

In some embodiments, access to IaaS, PaaS, or SaaS resources may beauthenticated. For example, a server or authentication server mayauthenticate a user via security certificates, HTTPS, or API keys. APIkeys may include various encryption standards such as, e.g., AdvancedEncryption Standard (AES). Data resources may be sent over TransportLayer Security (TLS) or Secure Sockets Layer (SSL).

The client 102 and server 106 may be deployed as and/or executed on anytype and form of computing device, e.g. a computer, network device orappliance capable of communicating on any type and form of network andperforming the operations described herein. FIGS. 1C and 1D depict blockdiagrams of a computing device 100 useful for practicing an embodimentof the client 102 or a server 106. As shown in FIGS. 1C and 1D, eachcomputing device 100 includes a central processing unit 121, and a mainmemory unit 122. As shown in FIG. 1C, a computing device 100 may includea storage device 128, an installation device 116, a network interface118, an I/O controller 123, display devices 124 a-124 n, a keyboard 126and a pointing device 127, e.g. a mouse. The storage device 128 mayinclude, without limitation, an operating system, software, and asoftware of a content distribution system (CDS) 120, for example, themessage delivery system 320 shown in FIG. 3A or the application providerproxy 420 shown in FIG. 4A. As shown in FIG. 1D, each computing device100 may also include additional optional elements, e.g. a memory port103, a bridge 170, one or more input/output devices 130 a-130 n(generally referred to using reference numeral 130), and a cache memory140 in communication with the central processing unit 121.

The central processing unit 121 is any logic circuitry that responds toand processes instructions fetched from the main memory unit 122. Inmany embodiments, the central processing unit 121 is provided by amicroprocessor unit, e.g.: those manufactured by Intel Corporation ofMountain View, Calif.; those manufactured by Motorola Corporation ofSchaumburg, Ill.; the ARM processor and TEGRA system on a chip (SoC)manufactured by Nvidia of Santa Clara, Calif.; the POWER7 processor,those manufactured by International Business Machines of White Plains,N.Y.; or those manufactured by Advanced Micro Devices of Sunnyvale,Calif. The computing device 100 may be based on any of these processors,or any other processor capable of operating as described herein. Thecentral processing unit 121 may utilize instruction level parallelism,thread level parallelism, different levels of cache, and multi-coreprocessors. A multi-core processor may include two or more processingunits on a single computing component. Examples of a multi-coreprocessors include the AMD PHENOM IIX2, INTEL CORE i5 and INTEL CORE i7.

Main memory unit 122 may include one or more memory chips capable ofstoring data and allowing any storage location to be directly accessedby the microprocessor 121. Main memory unit 122 may be volatile andfaster than storage 128 memory. Main memory units 122 may be Dynamicrandom access memory (DRAM) or any variants, including static randomaccess memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Fast PageMode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM(EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended DataOutput DRAM (BEDO DRAM), Single Data Rate Synchronous DRAM (SDR SDRAM),Double Data Rate SDRAM (DDR SDRAM), Direct Rambus DRAM (DRDRAM), orExtreme Data Rate DRAM (XDR DRAM). In some embodiments, the main memory122 or the storage 128 may be non-volatile; e.g., non-volatile readaccess memory (NVRAM), flash memory non-volatile static RAM (nvSRAM),Ferroelectric RAM (FeRAM), Magnetoresistive RAM (MRAM), Phase-changememory (PRAM), conductive-bridging RAM (CBRAM),Silicon-Oxide-Nitride-Oxide-Silicon (SONOS), Resistive RAM (RRAM),Racetrack, Nano-RAM (NRAM), or Millipede memory. The main memory 122 maybe based on any of the above described memory chips, or any otheravailable memory chips capable of operating as described herein. In theembodiment shown in FIG. 1C, the processor 121 communicates with mainmemory 122 via a system bus 150 (described in more detail below). FIG.1D depicts an embodiment of a computing device 100 in which theprocessor communicates directly with main memory 122 via a memory port103. For example, in FIG. 1D the main memory 122 may be DRDRAM.

FIG. 1D depicts an embodiment in which the main processor 121communicates directly with cache memory 140 via a secondary bus,sometimes referred to as a backside bus. In other embodiments, the mainprocessor 121 communicates with cache memory 140 using the system bus150. Cache memory 140 typically has a faster response time than mainmemory 122 and is typically provided by SRAM, BSRAM, or EDRAM. In theembodiment shown in FIG. 1D, the processor 121 communicates with variousI/O devices 130 via a local system bus 150. Various buses may be used toconnect the central processing unit 121 to any of the I/O devices 130,including a PCI bus, a PCI-X bus, or a PCI-Express bus, or a NuBus. Forembodiments in which the I/O device is a video display 124, theprocessor 121 may use an Advanced Graphics Port (AGP) to communicatewith the display 124 or the I/O controller 123 for the display 124. FIG.1D depicts an embodiment of a computer 100 in which the main processor121 communicates directly with I/O device 130 b or other processors 121′via HYPERTRANSPORT, RAPIDIO, or INFINIBAND communications technology.FIG. 1D also depicts an embodiment in which local busses and directcommunication are mixed: the processor 121 communicates with I/O device130 a using a local interconnect bus while communicating with I/O device130 b directly.

A wide variety of I/O devices 130 a-130 n may be present in thecomputing device 100. Input devices may include keyboards, mice,trackpads, trackballs, touchpads, touch mice, multi-touch touchpads andtouch mice, microphones, multi-array microphones, drawing tablets,cameras, single-lens reflex camera (SLR), digital SLR (DSLR), CMOSsensors, accelerometers, infrared optical sensors, pressure sensors,magnetometer sensors, angular rate sensors, depth sensors, proximitysensors, ambient light sensors, gyroscopic sensors, or other sensors.Output devices may include video displays, graphical displays, speakers,headphones, inkjet printers, laser printers, and 3D printers.

Devices 130 a-130 n may include a combination of multiple input oroutput devices, including, e.g., Microsoft KINECT, Nintendo Wiimote forthe WII, Nintendo WII U GAMEPAD, or Apple IPHONE. Some devices 130 a-130n allow gesture recognition inputs through combining some of the inputsand outputs. Some devices 130 a-130 n provides for facial recognitionwhich may be utilized as an input for different purposes includingauthentication and other commands. Some devices 130 a-130 n provides forvoice recognition and inputs, including, e.g., Microsoft KINECT, SIRIfor IPHONE by Apple, Google Now or Google Voice Search.

Additional devices 130 a-130 n have both input and output capabilities,including, e.g., haptic feedback devices, touchscreen displays, ormulti-touch displays. Touchscreen, multi-touch displays, touchpads,touch mice, or other touch sensing devices may use differenttechnologies to sense touch, including, e.g., capacitive, surfacecapacitive, projected capacitive touch (PCT), in-cell capacitive,resistive, infrared, waveguide, dispersive signal touch (DST), in-celloptical, surface acoustic wave (SAW), bending wave touch (BWT), orforce-based sensing technologies. Some multi-touch devices may allow twoor more contact points with the surface, allowing advanced functionalityincluding, e.g., pinch, spread, rotate, scroll, or other gestures. Sometouchscreen devices, including, e.g., Microsoft PIXELSENSE orMulti-Touch Collaboration Wall, may have larger surfaces, such as on atable-top or on a wall, and may also interact with other electronicdevices. Some I/O devices 130 a-130 n, display devices 124 a-124 n orgroup of devices may be augment reality devices. The I/O devices may becontrolled by an I/O controller 123 as shown in FIG. 1C. The I/Ocontroller may control one or more I/O devices, such as, e.g., akeyboard 126 and a pointing device 127, e.g., a mouse or optical pen.Furthermore, an I/O device may also provide storage and/or aninstallation medium 116 for the computing device 100. In still otherembodiments, the computing device 100 may provide USB connections (notshown) to receive handheld USB storage devices. In further embodiments,an I/O device 130 may be a bridge between the system bus 150 and anexternal communication bus, e.g. a USB bus, a SCSI bus, a FireWire bus,an Ethernet bus, a Gigabit Ethernet bus, a Fibre Channel bus, or aThunderbolt bus.

In some embodiments, display devices 124 a-124 n may be connected to I/Ocontroller 123. Display devices may include, e.g., liquid crystaldisplays (LCD), thin film transistor LCD (TFT-LCD), blue phase LCD,electronic papers (e-ink) displays, flexile displays, light emittingdiode displays (LED), digital light processing (DLP) displays, liquidcrystal on silicon (LCOS) displays, organic light-emitting diode (OLED)displays, active-matrix organic light-emitting diode (AMOLED) displays,liquid crystal laser displays, time-multiplexed optical shutter (TMOS)displays, or 3D displays. Examples of 3D displays may use, e.g.stereoscopy, polarization filters, active shutters, or autostereoscopy.Display devices 124 a-124 n may also be a head-mounted display (HMD). Insome embodiments, display devices 124 a-124 n or the corresponding I/Ocontrollers 123 may be controlled through or have hardware support forOPENGL or DIRECTX API or other graphics libraries.

In some embodiments, the computing device 100 may include or connect tomultiple display devices 124 a-124 n, which each may be of the same ordifferent type and/or form. As such, any of the I/O devices 130 a-130 nand/or the I/O controller 123 may include any type and/or form ofsuitable hardware, software, or combination of hardware and software tosupport, enable or provide for the connection and use of multipledisplay devices 124 a-124 n by the computing device 100. For example,the computing device 100 may include any type and/or form of videoadapter, video card, driver, and/or library to interface, communicate,connect or otherwise use the display devices 124 a-124 n. In oneembodiment, a video adapter may include multiple connectors to interfaceto multiple display devices 124 a-124 n. In other embodiments, thecomputing device 100 may include multiple video adapters, with eachvideo adapter connected to one or more of the display devices 124 a-124n. In some embodiments, any portion of the operating system of thecomputing device 100 may be configured for using multiple displays 124a-124 n. In other embodiments, one or more of the display devices 124a-124 n may be provided by one or more other computing devices 100 a or100 b connected to the computing device 100, via the network 104. Insome embodiments software may be designed and constructed to use anothercomputer's display device as a second display device 124 a for thecomputing device 100. For example, in one embodiment, an Apple iPad mayconnect to a computing device 100 and use the display of the device 100as an additional display screen that may be used as an extended desktop.One ordinarily skilled in the art will recognize and appreciate thevarious ways and embodiments that a computing device 100 may beconfigured to have multiple display devices 124 a-124 n.

Referring again to FIG. 1C, the computing device 100 may comprise astorage device 128 (e.g. one or more hard disk drives or redundantarrays of independent disks) for storing an operating system or otherrelated software, and for storing application software programs such asany program related to the software 120 for the content distributionsystem. Examples of storage device 128 include, e.g., hard disk drive(HDD); optical drive including CD drive, DVD drive, or BLU-RAY drive;solid-state drive (SSD); USB flash drive; or any other device suitablefor storing data. Some storage devices may include multiple volatile andnon-volatile memories, including, e.g., solid state hybrid drives thatcombine hard disks with solid state cache. Some storage device 128 maybe non-volatile, mutable, or read-only. Some storage device 128 may beinternal and connect to the computing device 100 via a bus 150. Somestorage device 128 may be external and connect to the computing device100 via a I/O device 130 that provides an external bus. Some storagedevice 128 may connect to the computing device 100 via the networkinterface 118 over a network 104, including, e.g., the Remote Disk forMACBOOK AIR by Apple. Some client devices 100 may not require anon-volatile storage device 128 and may be thin clients or zero clients102. Some storage device 128 may also be used as a installation device116, and may be suitable for installing software and programs.Additionally, the operating system and the software can be run from abootable medium, for example, a bootable CD, e.g. KNOPPIX, a bootable CDfor GNU/Linux that is available as a GNU/Linux distribution fromknoppix.net.

Client device 100 may also install software or application from anapplication distribution platform. Examples of application distributionplatforms include the App Store for iOS provided by Apple, Inc., the MacApp Store provided by Apple, Inc., GOOGLE PLAY for Android OS providedby Google Inc., Chrome Webstore for CHROME OS provided by Google Inc.,and Amazon Appstore for Android OS and KINDLE FIRE provided byAmazon.com, Inc. An application distribution platform may facilitateinstallation of software on a client device 102. An applicationdistribution platform may include a repository of applications on aserver 106 or a cloud 108, which the clients 102 a-102 n may access overa network 104. An application distribution platform may includeapplication developed and provided by various developers. A user of aclient device 102 may select, purchase and/or download an applicationvia the application distribution platform.

Furthermore, the computing device 100 may include a network interface118 to interface to the network 104 through a variety of connectionsincluding, but not limited to, standard telephone lines LAN or WAN links(e.g., 802.11, T1, T3, Gigabit Ethernet, Infiniband), broadbandconnections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet,Ethernet-over-SONET, ADSL, VDSL, BPON, GPON, fiber optical includingFiOS), wireless connections, or some combination of any or all of theabove. Connections can be established using a variety of communicationprotocols (e.g., TCP/IP, Ethernet, ARCNET, SONET, SDH, Fiber DistributedData Interface (FDDI), IEEE 802.11a/b/g/n/ac CDMA, GSM, WiMax and directasynchronous connections). In one embodiment, the computing device 100communicates with other computing devices 100′ via any type and/or formof gateway or tunneling protocol e.g. Secure Socket Layer (SSL) orTransport Layer Security (TLS), or the Citrix Gateway Protocolmanufactured by Citrix Systems, Inc. of Ft. Lauderdale, Fla. The networkinterface 118 may comprise a built-in network adapter, network interfacecard, PCMCIA network card, EXPRESSCARD network card, card bus networkadapter, wireless network adapter, USB network adapter, modem or anyother device suitable for interfacing the computing device 100 to anytype of network capable of communication and performing the operationsdescribed herein.

A computing device 100 of the sort depicted in FIGS. 1B and 1C mayoperate under the control of an operating system, which controlsscheduling of tasks and access to system resources. The computing device100 can be running any operating system such as any of the versions ofthe MICROSOFT WINDOWS operating systems, the different releases of theUnix and Linux operating systems, any version of the MAC OS forMacintosh computers, any embedded operating system, any real-timeoperating system, any open source operating system, any proprietaryoperating system, any operating systems for mobile computing devices, orany other operating system capable of running on the computing deviceand performing the operations described herein. Typical operatingsystems include, but are not limited to: WINDOWS 2000, WINDOWS Server2012, WINDOWS CE, WINDOWS Phone, WINDOWS XP, WINDOWS VISTA, and WINDOWS7, WINDOWS RT, and WINDOWS 8 all of which are manufactured by MicrosoftCorporation of Redmond, Wash.; MAC OS and iOS, manufactured by Apple,Inc. of Cupertino, Calif.; and Linux, a freely-available operatingsystem, e.g. Linux Mint distribution (“distro”) or Ubuntu, distributedby Canonical Ltd. of London, United Kingom; or Unix or other Unix-likederivative operating systems; and Android, designed by Google, ofMountain View, Calif., among others. Some operating systems, including,e.g., the CHROME OS by Google, may be used on zero clients or thinclients, including, e.g., CHROMEBOOKS.

The computer system 100 can be any workstation, telephone, desktopcomputer, laptop or notebook computer, netbook, ULTRABOOK, tablet,server, handheld computer, mobile telephone, smartphone or otherportable telecommunications device, media playing device, a gamingsystem, mobile computing device, or any other type and/or form ofcomputing, telecommunications or media device that is capable ofcommunication. The computer system 100 has sufficient processor powerand memory capacity to perform the operations described herein. In someembodiments, the computing device 100 may have different processors,operating systems, and input devices consistent with the device. TheSamsung GALAXY smartphones, e.g., operate under the control of Androidoperating system developed by Google, Inc. GALAXY smartphones receiveinput via a touch interface.

In some embodiments, the computing device 100 is a gaming system. Forexample, the computer system 100 may comprise a PLAYSTATION 3, orPERSONAL PLAYSTATION PORTABLE (PSP), or a PLAYSTATION VITA devicemanufactured by the Sony Corporation of Tokyo, Japan, a NINTENDO DS,NINTENDO 3DS, NINTENDO WII, or a NINTENDO WII U device manufactured byNintendo Co., Ltd., of Kyoto, Japan, an XBOX 360 device manufactured bythe Microsoft Corporation of Redmond, Wash.

In some embodiments, the computing device 100 is a digital audio playersuch as the Apple IPOD, IPOD Touch, and IPOD NANO lines of devices,manufactured by Apple Computer of Cupertino, Calif. Some digital audioplayers may have other functionality, including, e.g., a gaming systemor any functionality made available by an application from a digitalapplication distribution platform. For example, the IPOD Touch mayaccess the Apple App Store. In some embodiments, the computing device100 is a portable media player or digital audio player supporting fileformats including, but not limited to, MP3, WAV, M4A/AAC, WMA ProtectedAAC, RIFF, Audible audiobook, Apple Lossless audio file formats and.mov, .m4v, and .mp4 MPEG-4 (H.264/MPEG-4 AVC) video file formats.

In some embodiments, the computing device 100 is a tablet e.g. the IPADline of devices by Apple; GALAXY TAB family of devices by Samsung; orKINDLE FIRE, by Amazon.com, Inc. of Seattle, Wash. In other embodiments,the computing device 100 is a eBook reader, e.g. the KINDLE family ofdevices by Amazon.com, or NOOK family of devices by Barnes & Noble, Inc.of New York City, N.Y.

In some embodiments, the communications device 102 includes acombination of devices, e.g. a smartphone combined with a digital audioplayer or portable media player. For example, one of these embodimentsis a smartphone, e.g. the IPHONE family of smartphones manufactured byApple, Inc.; a Samsung GALAXY family of smartphones manufactured bySamsung, Inc; or a Motorola DROID family of smartphones. In yet anotherembodiment, the communications device 102 is a laptop or desktopcomputer equipped with a web browser and a microphone and speakersystem, e.g. a telephony headset. In these embodiments, thecommunications devices 102 are web-enabled and can receive and initiatephone calls. In some embodiments, a laptop or desktop computer is alsoequipped with a webcam or other video capture device that enables videochat and video call.

In some embodiments, the status of one or more machines 102, 106 in thenetwork 104 is monitored, generally as part of network management. Inone of these embodiments, the status of a machine may include anidentification of load information (e.g., the number of processes on themachine, CPU and memory utilization), of port information (e.g., thenumber of available communication ports and the port addresses), or ofsession status (e.g., the duration and type of processes, and whether aprocess is active or idle). In another of these embodiments, thisinformation may be identified by a plurality of metrics, and theplurality of metrics can be applied at least in part towards decisionsin load distribution, network traffic management, and network failurerecovery as well as any aspects of operations of the present solutiondescribed herein. Aspects of the operating environments and componentsdescribed above will become apparent in the context of the systems andmethods disclosed herein

B. Communication Technology Platform

Referring now to FIG. 2A, a block diagram depicting an environmentcomprising a communication technology platform useful in connection withthe methods and systems described herein is shown. The communicationtechnology platform 202 facilitates the delivery of messages from aclient to one or more consumers associated with the client. Inparticular, the communication technology platform 202 can be configuredto receive via an SMPP protocol, a request from the client to send amessage to one or more consumers of the client via any of a plurality ofdelivery channels. In some implementations, the client may be a company,business or any other entity that may wish to send messages to one ormore recipients. In some implementations, the consumers may beassociated with the client either as current, past or future users,members or subscribers, or through any other form of association inwhich the client and consumers may communicate with one another.

More generally, when a client wants to send a message to one or moreconsumers associated with the client, the client may use an applicationprovider, such as the communication technology platform 202 to create arequest to send out messages. The application provider can communicatewith an aggregator, which in turn can communicate with one or morewireless carriers. The wireless carriers can communicate with theconsumer devices associated with the consumers to whom the client wouldlike to send messages. In some implementations, the application providercan be coupled to the aggregator.

In some implementations, a client, such as a company may utilize one ormore short codes for marketing or other purposes. The short code can beassigned to a particular application, which oftentimes, is provided bythe application provider used by the client.

Each message addressed to an active short code is routed to anapplication. Although clients can develop and host applications, thereare application providers, such as the communication technology platform202, that may specialize in software development and hosting for mobilemessaging applications. Application providers can provide one or moretypes of applications, such as voting/polling, marketing or gaming.

To use an active short code, the client may need connectivity to thenetworks of participating wireless carriers, so any message addressed tothe active short code can reach the application to which the short codeis assigned. In some implementations, the most common method forconnecting to a wireless network is Short Message Peer to Peer (SMPP)over a secured virtual private network (VPN) connection.

Aggregators typically have authorized connections to multiple wirelessnetworks. In some implementations, aggregators also maintain thesecurity, technical and service level requirements of each wirelessnetwork. Wireless carriers, also sometimes referred to as mobileoperators, wireless networks or wireless service providers are thecompanies from which customers can purchase connection services fortheir consumer devices, for example, mobile phones.

Referring now again to FIG. 2A, in brief overview, the communicationtechnology platform 202 can be configured to communicate with one ormore aggregators 204. The aggregators 204 are configured to send andreceive data packets from and to one or more wireless carriers 206. Thewireless carriers 206 can communicate with one or more clients and oneor more customers of the clients. In some implementations, theaggregator 204 can communicate with one or more clients and customers ofthe clients via the wireless carriers 206.

The communication technology platform 202 can include a flexible andefficient messaging and application framework 210, a runtimeconfiguration database 220, a transaction database 230 that archives alltransactions for analytics and reporting, a set of web services 240 toconfigure and access application data and a management and reportingcenter 250 configured to provide a simple user interface.

The communication technology platform 202 can be designed, constructedor configured as a flexible, stable, extensible, high performanceplatform that can handle a very wide variety of application types. Inaddition to marketing applications, the communication technologyplatform 202 may be configured to handle various message-based services.Examples of such message-based services can include feature rich mobilecampaign management services, image transmission services via MultimediaMessaging Service (MMS), social applications via one or more socialnetworks or social media applications (for example, Facebook andTwitter), text-based services for ordering products, location-basedservices and other third-party applications that send or receivemessages (for example, online trading applications to customerrelationship management (CRM) applications).

The messaging and application framework 210 may be the core of thecommunication technology platform 202. The framework 210 can include twodiscrete components—an application stack 212, which can be an efficient,configurable application management framework and a message processor214, such as a transceiver.

The message processor 214 can be configured to parse incoming messagesreceived by the aggregator to identify the message type, carrier,sender, short code and the message content. The application stack 212can be configured to process the parsed message to determine whichapplication will handle the message. The application may be internal tothe application stack or related to a third party application or system.Once the application is identified and accessed, the message processor214 can send a response, while the application stack 212 can changestates to receive the next message from the same sender in a structuredconversation.

The messaging and application framework 210 can handle streams ofmessages from multiple carriers on multiple short codes in relation tomultiple applications. For every application, the messaging andapplication framework 210 maintains the context of each individualinteraction in readiness for the next incoming message in that thread.The application stack 214 can manage a very large number of applicationsat very high speed without losing context. Additional details of theapplication stack 214 are provided below with respect to FIG. 2B.

The runtime and configuration database 220 can be designed, constructedor configured to maintain contextual data to facilitate the initiationof interactions for any application and to maintain the status of theinteraction thereafter. The runtime and configuration database 220 canalso be configured to include data generated by such applications.

The transaction log database 230 can be designed, constructed orconfigured to maintain a log of transactions handled by the messagingand application framework 210. In some implementations, there can be adeliberate separation between the runtime transaction system that themessaging and application framework 210 provides and the analyticssubsystem. This is so the analytics processing on the system can be runat any time without impacting the runtime system's performance.

The web services 240 can be designed, constructed or configured tocontrol access to the runtime and configuration database 220, to one ormore third party applications 260 and to the management and reportingcenter 250. In this way, the web services 240 can enable third partyapplications 260 to access data associated with the applications withinthe application stack 210 and can enable the management and reportingcenter 250 to set application data and construct reports of theactivities of the one or more applications within the application stack210. In some implementations, the web services 240 can be a web servicesApplication Programming Interface (API).

The management and reporting center 250 can be designed, constructed orconfigured as a flexible platform that enables management and reportingfunctions to be optimized for different application types. Themanagement and reporting center can be configured to allow clients tobuild, manage and analyze mobile marketing campaigns. The management andreporting center 250 can be configured to provide several configurableoptions, including but not limited to branding and multi-tiered accountmanagement, reporting and billing. These options can be used in part toallow marketing service providers to easily incorporate mobile marketingservices into their portfolio of customer offerings. The management andreporting center 250 can also be configured to interface with a standardtwo-way API for custom integration with other web services. In someimplementations, the management and reporting center 250 and the webservices 240 can be configured to communicate over an application layerprotocol, for example, HTTP or HTTPS.

One of the common applications of the communication technology platform202 is in the context of a mobile marketing campaign (MMC), in which thecommunication technology platform 202 allows for management andreporting of mobile campaigns. FIG. 2B depicts a process flow associatedwith a mobile marketing campaign managed by the communication technologyplatform. In brief overview, the communication technology platform 202can exchange messages with clients and customers of the clients via theaggregator 204, which communicates with the clients and customers viathe wireless carriers.

The communication technology platform 202 can include the messaging andapplication framework 210, the runtime configuration database 220 shownas a mobile originated log database, the transaction database 230 shownas the mobile marketing campaign (MMC) database, a set of web services240 shown as a mobile marketing campaign Simple Object Access Protocol(SOAP) API, and the management and reporting center 250 shown as amobile marketing center.

In some implementations, campaign information can stored in the MMCdatabase 230 using the MMC SOAP API 240. In some implementations,clients can choose to use an MMC Graphical User Interface (GUI) orprogrammatically configure the campaigns using APIs within their ownmanaged applications.

A basic flow for a mobile marketing campaign, for example, an SMScampaign, handled by the communication technology platform 202 can besummarized in accordance with a series of steps shown in FIG. 2B. Asdepicted in step 1 of FIG. 2B, the messaging and application framework210 receives a MO (Mobile Originated) message from a wireless carrier206 via the aggregator 204. The message includes information associatedwith the sender, recipient (for example, a short code associated withthe recipient), carrier, message body, and message type (for example,SMS, MMS, LBS). As depicted in step 2 of FIG. 2B, the messaging andapplication framework 210 can be configured to log the raw MO content inthe into a campaign analytics platform 265 of the messaging andapplication framework 210. As depicted in step 3 of FIG. 2B, themessaging and application framework 210 requests and retrieves anyprevious application context information associated with the sender andrecipient from the runtime and configuration database 220.

As depicted in step 4 of FIG. 2B, the application stack 212 receivesinformation associated with the message and reviews the message body. Insome implementations, the information associated with the message isstored in the runtime and configuration database 220. In someimplementations, each application in the application stack 212 may begiven the opportunity to review the message body and determine if itshould be that application to handle the message. Examples ofapplications include an API callback application, a reply application, atext2screen application, a STOP/HELP application, a survey application,an email capture application, a keyword comment application, a text2winapplication, a vote poll application, an auto responder application, akeyword application, a vote poll blast application, an RSS responseapplication and a default application amongst others. As depicted instep 5 of FIG. 2B, one or more of the applications in the applicationstack 212 handle or process the message.

As depicted in step 6 of FIG. 2B, the MMC database 230 can thendetermine additional application data and log context data generated bythe one or more applications handling the message. As depicted in step 7of FIG. 2B, the application stack 212 then generates a reply to the MOmessage received by the messaging and application framework 210 andtransmits the reply as a mobile terminated (MT) message via theaggregator 204. The messaging and application framework 210 then logsthe MT message along with any additional meta-data added to the MT bythe application stack 212 in the campaign analytics platform 260 of themessaging and application framework 210 and the runtime andconfiguration database 220.

FIG. 2C is a block diagram depicting an embodiment of an aggregatorimplementing the communication technology platform. The hardwarearchitecture 270 comprises one or more servers for eachclient-application provider combination. In general, clients may havemore than one server to enable the required level of throughput,performance and security. FIG. 2C shows a typical configuration for avery large volume client. In some implementations, the hardwarearchitecture can be performed on a single server. In someimplementations, the hardware architecture can be performed on more thanone server. For example, in the implementation depicted in FIG. 2C, fourseparate servers are configured to form a part of the hardwarearchitecture.

The first server 272 can be configured to handle the Short MessagePeer-to-Peer (SMPP) protocol interface and log all the traffic for dataanalysis by the analytics platform. The traffic includes MobileOriginated (MO) messages, Mobile Terminated (MT) messages and DeliveryReport (DLR) messages. The second server 274 can be configured to handlethe MO stack and application databases. The second server 274 can beload balanced as needed for high volume. Although the custom appdatabase is shown to reside on the second server, in someimplementations, it may reside on the third server. The third server 276includes a marketing center database and a mobile campaign manager, forexample, the MMC or management and reporting center 250 as shown in FIG.2B. The fourth server 278 can be configured to include the analyticsplatform 265.

C. Systems and Methods for Delivering Messages Received via SMPPProtocol over a Plurality of Delivery Channels

Various embodiments disclosed herein are directed to methods and systemsfor delivering messages received via the Short Message Peer-to-Peer(SMPP) protocol over a plurality of delivery channels. A messagedelivery system acting as an intermediary between one or more clientsand one or more consumers can be configured to establish a connectionwith the client via an SMPP protocol. In some implementations, theclient may be a company, business or any other entity that may wish tosend messages to one or more recipients. The consumers may be current,past or future customers of the client. In some implementations, theconsumers may be associated with the client either as current, past orfuture users, members or subscribers, or through any other form ofassociation in which the client and consumers may communicate with oneanother. The message delivery system can receive, from the client viathe SMPP protocol, an SMPP request to deliver a message to at least oneof a plurality of consumers. The request can include the message to bedelivered and identify a delivery policy according to which the messageis to be delivered to one or more consumers. The delivery policy caninclude one or more rules for delivering the message, including but notlimited to identifying one or more target delivery channels throughwhich to deliver the message, identifying a time at which to deliver themessage, identifying one or more conditions for delivering the message,for example, a condition requiring that the consumer device be locatedwithin a particular geographic region, amongst other rules.

In some implementations, the message delivery system can inspect therequest to identify the delivery policy. The message delivery system canthen process the request and based on the target delivery channelthrough which to deliver the message identified in the delivery policy,transmit the message included within the request to the consumer inaccordance with the delivery policy. In some implementations, thedelivery channel can be a push notification delivery channel throughwhich the message is delivered to a consumer device as a pushnotification via an application operating on the consumer device. Insome implementations, the delivery channel can be a Short MessageService (SMS) delivery channel through which the message is delivered toa consumer device as an SMS message. In some implementations, thedelivery channel can be an email delivery channel through which themessage is delivered to a consumer device as an email message via a mailapplication. In some implementations, the delivery channel can be aninstant messaging channel through which the message is delivered to aconsumer device as an instant message via an instant messagingapplication.

In some implementations, the message delivery system can be configuredto establish an SMPP connection with a client agent operating on aclient, over which the message delivery system and the client cancommunicate. The client agent can be configured to generate an SMPPrequest that includes the message to be delivered as well as thedelivery policy according to which the message is to be delivered. Inaddition, the message delivery system can be configured to communicatewith an application operating on the consumer device through which themessage delivery system can send push notifications to the consumerdevice. In some implementations, the message delivery system canestablish a secure connection with the application and deliver pushnotifications through the secure connection. In some otherimplementations, the message delivery system can send push notificationsthrough a third-party push notification service that is configured tosend the push notification to the application operating on the consumerdevice.

FIG. 3A is a block diagram illustrating a computer networked environmentfor delivering messages received via the SMPP protocol over any of aplurality of delivery channels are provided in accordance with variousembodiments. The environment includes a message delivery system 320(e.g. a message deliverer) configured to allow one or more clients 310to communicate with one or more consumers via consumer device 340 overone or more networks, such as the network 104.

In some implementations, a message deliverer can execute on a deviceintermediary between a client device and a plurality of consumerdevices. For instance, the message delivery system 320 can be astandalone entity intermediary to the client and the consumers. In someimplementations, the message delivery system 320 can operate on theclient 310. In some implementations, the message delivery system 320 canoperate on an entity intermediary to the client and the consumers, forexample, on an aggregator, such as the aggregator 204 shown in FIGS. 2Aand 2B, an SMSC or a push notification service.

A consumer can be an individual or entity associated with a consumerdevice 340, which can be configured to receive messages 316 from one ormore clients 302 via the message delivery system 320. The consumer canhave a particular relationship with the client. For example, theconsumer can be an existing or potential customer of the client orcurrent or potential user of the client's services, amongst others. Insome implementations, the consumer device 340 can be configured toreceive messages via an application 342 operating or executing on theconsumer device 340. In some implementations, the application 342 isassociated with the message delivery system 320 such that the messagedelivery system 320 is capable of sending messages to the consumerdevice 340 via the application 342. In some implementations, theconsumer device 340 can be associated with one or more consumeridentifiers that uniquely identify the consumer to the message deliverysystem 320. Examples of the consumer identifier can include one or moreof a phone number, a network device identifier, such as a MAC address ora push token identifier associated with the application 342 operating onthe consumer 340.

The message delivery system 320 may execute on one or more servers, suchas the server 106 shown in FIG. 1A. The message delivery system 320, andany modules or components thereof, may comprise one or moreapplications, programs, libraries, services, processes, scripts, tasksor any type and form of executable instructions executing on one or moredevices, such as servers. The message delivery system 320, and anymodules or components thereof, may use any type and form of database forstorage and retrieval of data. The message delivery system 320 maycomprise function, logic and operations to perform any of the methodsdescribed herein.

The message delivery system 320 can include a memory having processorexecutable instructions stored thereon and a processor configured toexecute the processor executable instructions stored on the memory. Themessage delivery system 320 may configure the processor to perform anyof the methods described herein.

The message delivery system 320 can deliver messages received via anSMPP protocol over one or more delivery channels. The message deliverysystem 320 can serve as an SMPP bridge through which one or more clients310 can communicate with one or more recipient consumer devices 340using the SMPP protocol to send messages.

In some implementations, the message delivery system 320 may establishan SMPP connection with the client 310 device based on SMPP protocol,the SMPP connection for communicating SMS messages. In someimplementations, the message delivery system 320 can establish an SMPPconnection with the client 310 through which the client can send one ormore requests 314 to deliver a message 316 to one or more consumerdevices 340. In some implementations, the message delivery system 320can establish an SMPP connection with a client agent 312 operating onthe client 310.

The message delivery system 320 may receive, from the client device 310over the SMPP connection, a first request, via the SMPP protocol, todeliver a message to at least one consumer device 340 of the pluralityof consumer devices. The first request can include the message and adelivery policy. In some implementations, the delivery policy canspecify one or more non-SMS delivery channels 330 through which todeliver the message.

The message delivery system 320 can be configured to deliver messages316 to the consumer devices 340 over one or more delivery channels. Insome implementations, the message delivery system may employ theservices of an intermediary to deliver the message to the consumerdevices 340. The intermediary can be a short message service center(SMSC) in situations where the message is to be delivered as an SMSmessage. The intermediary can be a third-party push notificationservice, for example, Apple Push Notification Service (APNS) or GoogleCloud Messaging (GCM), in situations where the message is to bedelivered as a push notification.

The message delivery system 320 can include a request parser 322, an SMSmanager 324, a notification manager 326 and a consumer profile database328. The message delivery system 320 can also include one or moreadditional modules configured to manage the delivery of messages acrossone or more additional delivery channels, including non-SMS deliverychannels, for example, an email manager, a voice manager, amongstothers. In some implementations, the non-SMS delivery channels caninclude a push notification delivery channel through which the messageis delivered to a consumer device 340 as a push notification via anapplication operating on the consumer device, an instant messagingchannel through which the message is delivered to a consumer device 340as an instant message via an instant messaging application, amongothers.

The request parser 322 may comprise one or more applications, programs,libraries, services, processes, scripts, tasks or any type and form ofexecutable instructions executing on one or more devices, and can bedesigned, constructed or configured to establish an SMPP connection withthe client 310 (e.g. client device). The request parser 322 of themessage delivery system 320 may establish an SMPP connection with theclient device based on SMPP protocol. The SMPP connection can beestablished for communicating SMS messages. In some implementations, theSMPP connection can be established to allow the client device 310 tosend requests to deliver notifications or messages to consumer devicesvia the message delivery system 320.

The SMPP protocol is an open, industry standard protocol designed toprovide a flexible data communication interface for the transfer ofshort message data between entities, such as the client 310 and themessage delivery system 320. The SMPP protocol can be based on pairs ofrequest/response protocol data units (PDUs 314) or packets exchangedover OSI layer 4 connections. An SMPP PDU 314 can start with a headerfollowed by a body. The header can include one or more fields. Thefields can include a command length indicating the overall length of thePDU in octets, a command identifier identifying the SMPP operation, thecommand status indicating if the command is a request or a response anda sequence number used to correlate requests and response within an SMPPsession. The header can include one or more other fields. The PDU bodycan include a message 316 to be delivered and can include informationidentifying a delivery policy 318 for delivering the message 316. Inaddition, the PDU 314 can include information identifying the sender ofthe PDU and information identifying the intended recipient of the PDU314. In some implementations, the PDU 314 can also include informationidentifying the intended recipient of the message included within thePDU.

The request parser 322 can be configured to receive SMPP requests orPDUs 314 over the SMPP protocol. The received SMPP requests 314 caninclude one or more additional fields that can include additionalinformation. These additional fields are sometimes referred to as TagLength Value fields (TLVs). The TLVs can be used to extend the SMPPprotocol with more advanced features. TLVs can be added as a byte streamat the end of the standard SMPP PDUs. In some implementations, the firsttwo bytes can be used to identify the TLV, the third and fourth bytescan indicate the length of the actual data which follows directly afterthese bytes.

The request parser 322 can be configured to parse SMPP requests 314received by the message delivery system. The requests 314 can berequests received from a client intended to be delivered to a mobiledevice, sometimes referred to as a mobile terminated (MT) request. Therequests 314 can be requests received from a mobile device intended tobe delivered to a client, sometimes referred to as a mobile originated(MO) request. The message delivery system 320 can also receive othertypes of requests, such as delivery receipt requests as well asresponses to both MT and MO requests.

In some implementations, the request parser 322 may be configured toinspect a header of the first request and identify fields of the headerof the first request. The request parser 322 can be configured to thendetermine, from values of the identified fields, the delivery policyaccording to which to deliver the message. In some implementations, therequest parser 322 can analyze the TLVs associated with a received SMPPrequest 314 to determine how to process messages included within theSMPP request 314. In addition, the request parser 322 can be configuredto parse information associated with the sender of the SMPP request 314,the intended recipients of the one or more messages included within theSMPP request, as well as other information. The request parser 322 canbe configured to identify the sender of the SMPP request 314 byidentifying a sending address associated with the SMPP request. In someimplementations, the request parser 322 can identify the sender bydetermining a value stored in a TLV of the SMPP request. In someimplementations, the request parser 322 can be configured toauthenticate that a received PDU 314 originated from a client authorizedto send PDUs to the message delivery system 320.

In some implementations, the request parser 322 can identify a deliverypolicy 318 associated with the request 314. In some implementations, therequest parser 322 or the message delivery system 320 may identify, fromthe delivery policy in the first request, the one or more non-SMSdelivery channels over which to deliver the message included in therequest to the client device. In some implementations, the requestparser 322 may identify the one or more non-SMS delivery channels. Thedelivery policy 318 can be included in one or more fields or TLVsassociated with the SMPP request 314. The client agent operating on theclient 310 can be configured to include the delivery policy 318 in theSMPP request 314 received by the request parser 322. The delivery policy318 associated with a request can include one or more rules fordelivering the message 316 included within the request 314. The deliverypolicy 318 can identify or specify one or more consumers to which themessage 316 is to be delivered, the one or more target delivery channels330 a-330 n through which the message 316 is to be delivered, the timeat which the message 316 is to be delivered, and one or more additionalconditions upon which the message is to be delivered, amongst others. Insome implementations, the delivery policy can identify one or more ofone or more consumer devices to which the message is to be delivered,one or more non-SMS delivery channels according to which the message isto be delivered, a time at which the message is to be delivered, ageographic location the consumer device has to be located within for themessage to be delivered to the consumer device, among others.

In some implementations, the delivery policy 318 can specify atriggering condition, which when triggered, causes the message to bedelivered. In some implementations, the delivery policy 318 can requirethe message delivery system 320 to deliver a message 316 upon theoccurrence of a triggering event. The event can be associated with aconsumer device 340 or an event unrelated to a consumer device. Anexample of an event associated with a consumer device can include theconsumer device being located within a predefined geographic area. Insome such implementations, the message delivery system 320 can beconfigured to receive geographic location information from the consumerdevice 340. In some implementations, the message delivery system 320 canretrieve such information through an application operating on theconsumer device 340, which can be configured to provide geographiclocation information to the message delivery system 320. For situationsin which the application collects and shares personal information aboutthe consumer, the consumer may be provided with an opportunity to optin/out of programs or features that may collect and share personalinformation, for example, information about a user's preferences or auser's current location. An example of an event unrelated to a consumerdevice can be a news related event. For instance, the event can be astock price falling below a threshold price. This can trigger thedelivery of a message from the client to the consumer device. Forexample, the client can be a stock advisor to the consumer and can senda message recommending the consumer to purchase the stock as the stockprice is now below the threshold price. In some implementations, themessage delivery system can be configured to receive informationassociated with such triggering events from the client itself or fromone or more additional databases or servers, for instance, a stock pricemonitoring server. In some implementations, the delivery policy canspecify an application executing on a mobile device (e.g. a consumerdevice 340) via which to present the message 316 as a notification onthe consumer device 340. In some implementations, the delivery policycan identify a type of message included in the request. Message typescan be classified based on the type of client, the identity of theclient, a priority level of the message, among others.

The request parser 322 can be configured to determine one or more targetdelivery channels 330 through which the message 316 included within theSMPP request 314 is to be delivered. In some implementations, therequest parser 322 can be configured to inspect the delivery policy 318to determine the target delivery channel 330. Upon the request parser322 determining the target delivery channel 330, the request parser 322can invoke the appropriate delivery channel manager to process therequest 314 and send the message 316 via the target delivery channel.For example, if the target delivery channel 330 is an SMS deliverychannel 330 a, the request parser 322 can invoke the SMS manager 324 toprocess the request. If the target delivery channel is a pushnotification channel 330 b, the request parser 322 can invoke thenotification manager 326 to process the request. In someimplementations, the request parser 322 or the message delivery system320 may invoke one or more non-SMS delivery channel managers, such as anemail manager and a voice manager.

One or more of the SMS manager 324, notification manager 326, and one ormore non-SMS delivery channel managers in the message delivery system320 may transmit, a second request to deliver the message via the one ormore non-SMS delivery channels to the at least one consumer device. Insome implementations, one or more non-SMS delivery channels (which caninclude the notification manager 326) may transmit the second request.In some implementations, for the one or more non-SMS delivery channels,a second request to deliver the message can be delivered via the one ormore non-SMS delivery channels to the at least one consumer device. Insome implementations, the message delivery system 320 may transmit, fora first non-SMS delivery channel, a corresponding second request to afirst entity configured to transmit the message to the consumer devicevia the first non-SMS delivery channel, and transmit, for a secondnon-SMS delivery channel, another corresponding second request to asecond entity configured to transmit the message to the consumer devicevia the second non-SMS delivery channel. In some implementations, theone or more of the SMS manager 324, notification manager 326, one ormore non-SMS delivery channel managers in the message delivery system320 may transmit the message included in the second request to theconsumer device 340 for presentation via an application 342 executing onthe client device, the application 342 specific to the client device340.

The SMS manager 324 may comprise one or more applications, programs,libraries, services, processes, scripts, tasks or any type and form ofexecutable instructions executing on one or more devices, and can bedesigned, constructed or configured to manage the delivery of messagesvia SMS. The SMS manager 324 can be configured to generate an SMSmessage in response to the request parser 322 determining that adelivery policy of the request indicates that the message includedwithin the request is to be delivered as an SMS message. The SMS manager324 may be configured to send an SMS message to a consumer device via anSMSC or other intermediary device.

The SMS manager 324 can be configured to include the message 316included within the SMPP request received from the client in the SMSmessage 332 a. The SMS manager 324 can configure the SMS message 332 asuch that the SMS message 332 a identifies the client as the sender ofthe SMS. The SMS manager 324 can include a phone number or short codeassociated with the client in the SMS message. In some implementations,the SMS manager 324 can be configured to generate an SMS message 332 athat includes the short code associated with the message delivery system320. In some such implementations, the SMS message 332 a can includeother information that identifies the client requesting the SMS messageto be sent. For example, the SMS message can identify the client in thebody of the message or can include an identifier in one of the fields ofthe SMS message. In this way, the message delivery system 320 canmaintain fewer short codes than the number of clients it services. Inother implementations, each client can have a dedicated short code.

The SMS manager 324 can also be configured to receive responses to theSMS messages 332 a sent to the consumer devices 340. In someimplementations, the responses include information that allows the SMSmanager 324 to identify the SMS message to which the responsecorresponds. In some implementations, the SMS manager 324 can extractinformation from the response and have it delivered to the client viathe established SMPP connection.

The notification manager 326 may comprise one or more applications,programs, libraries, services, processes, scripts, tasks or any type andform of executable instructions executing on one or more devices, andcan be designed, constructed or configured to manage the delivery ofnotifications to one or more consumer devices 340. The notificationmanager 326 can be configured to manage the delivery of notifications332 a-332 n across a wide variety of applications or platforms,including but not limited to SMS messages, push notifications for one ormore applications, emails for email applications, social networkingposts for social networking applications or programs, pages forpager-based applications, instant messages for instant messaging basedapplications, amongst others. The notification manager 326 can beconfigured to deliver the notifications 332 a-332 n over a plurality ofdifferent notification channels 330 a-330 n.

In some implementations, the notification manager 326 can be configuredto generate a push notification request 332 b in response to the requestparser 322 determining that a message included in a received SMPPrequest is to be delivered as a push notification. The notificationmanager 326 can be configured to include the message 316 included withinthe SMPP request in the push notification request 332 b. Thenotification manager 326 can configure the push notification request toidentify the client that sent the corresponding SMPP request as thesender of the push notification request. In some implementations, thenotification manager 326 can configure the push notification request toidentify the message delivery system as the sender of the pushnotification request.

The notification manager 326 can send the push notification request tothe consumer device 340 or to a third-party push notification service334 through which push notifications can be delivered to the consumerdevice 340. Each consumer device 340 that utilizes the services of athird-party push notification service for delivering push notificationscan establish an accredited and encrypted IP connection with thethird-party push notification service and can receive notifications overthis persistent connection. If a notification for an application 342installed on the consumer device 340 arrives when that application 342is not running, the consumer device 340 can alert the consumerassociated with the consumer device 340 that the application 342 hasdata waiting for it. A provider, such as the message delivery system320, can originate a push notification in the form of a pushnotification request. The message delivery system 320 can send the pushnotification to the third-party push notification service, for example,through a persistent and secure channel. When new data for a consumerdevice arrives, the message delivery system 320 can prepare and send apush notification request through the channel to the third-party pushnotification service, which can subsequently push the push notificationto the intended consumer device.

The third-party push notification service 334 can transport and route apush notification from a given provider, such as the message deliverysystem 320 to a given device, such as a consumer device 340. A pushnotification can be a short message that includes two major pieces ofdata: a device token and the payload. The device token can be an opaqueidentifier of a consumer device that the third-party notificationservice gives to the consumer device 340 when it first connects with thethird-party notification service. The consumer device 340 can share thedevice token with the message delivery system 320 associated with anapplication 342 operating on the consumer device 340. Thereafter, forthe message delivery system 320 to deliver a push notification on theconsumer device 340, the message delivery system 320 has to provide thedevice token along with the push notification to be delivered. Thedevice token is the basis for establishing trust that the routing of aparticular notification is legitimate. The payload can be information,for example, a JSON-defined property list, that specifies how a consumerof the consumer device is to be alerted.

The third-party push notification service 334 can decrypt the tokenusing the token key, thereby ensuring that the notification is valid.The third-party push notification service then uses the device IDcontained in the device token to determine the destination device forthe notification.

The message delivery system 310 may be designed, constructed and/orconfigured to communicate with and/or interface to a plurality ofdifferent content repositories 328. In some embodiments, the messagedelivery system 310 can communicate with the content repositories 328over one or more networks 104, such as to a remote server or cloudstorage service. Content repositories 328 may include any type and formof storage or storage service for storing data such as digital content.Examples of such content repositories include servers or servicesprovided by Dropbox, Box.com, Google, amongst others. In someembodiments, the content repositories are maintained by the messagedelivery system 310. In some embodiments, the content repositories arelocated local to the message delivery system 310.

In some implementations, the content repositories 328 can store content,including information associated with one or more clients and one ormore consumers. A content repository, for example, a client contentrepository can include information associated with one or more clients,including client information, information relating to an SMPP protocolconnection between the client and the delivery notification system, aconsumer list of the client, client preferences, one or morenotification policies, as well as a record of any messages received fromor delivered to the client. Another content repository, for example, aconsumer profile database can be configured to maintain consumerprofiles for one or more consumers associated with one or more clients.The consumer profiles can include information related to notificationchannels associated with the consumers, preferences of the consumer,tokens associated with any push notification services through which pushnotifications are to be delivered to the consumer, telephone numbers,amongst others.

In some implementations, the client 310, via the client agent 312, canbe configured to generate and transmit a request to deliver a message toone or more users. The client 310 can be configured to transmit therequest to the message delivery system 320, which is configured toprocess the request and deliver the message to the users intended by theclient. Client agent 312 may comprise one or more applications,programs, libraries, services, processes, scripts, tasks or any type andform of executable instructions executing on one or more devices, andcan be designed, constructed or configured to perform various functionsassociated with generating and transmitting a request to deliver amessage to one or more consumers. In some implementations, the clientagent 312 is configured to establish a connection with the messagedelivery system 320. In some implementations, the client agent 312 isconfigured to establish an SMPP protocol connection with the messagedelivery system 320.

In some implementations, the client agent 312, in connection with themessage delivery system 320 (e.g. message deliverer) may establish theSMPP connection. The client agent 312 may operate or execute on theclient device 310. In some implementations, the processor of the messagedeliverer may establish the SMPP connection with the client agent 213.

The client agent 312 can be configured to present a user interfacethrough which an operator associated with the client can interact withthe client agent. In some implementations, the user interface can beconfigured to allow an operator at the client to create an SMPP requestto deliver a message to one or more consumers. The user interface canprovide options for selecting the delivery channel through which themessage is to be delivered, the time at which it is to be delivered, oneor more conditions or triggering events upon which the message is to bedelivered, other particular delivery instructions including whether torequest a read receipt delivery receipt responses, amongst others.

In some implementations, the client agent 312 can be configured to haveone or more predefined rules for generating SMPP requests. These rulescan be based on one or more triggering events. For example, using theexample of a bank wishing to deliver messages to its customers, a clientagent of the bank can be configured to monitor the bank accounts of thebank's customers. The client agent can further be configured to monitorfor a triggering event, such as a bank account balance falling below$200. The client agent can further be configured to automaticallygenerate an SMPP request including a message alerting the customer thattheir bank account balance has fallen below $200. Moreover, the clientagent can be configured to include a delivery policy that may bespecific to the customer or may be specific to the type of messageindicating how to deliver the message to the customer. The client agent312 can be configured to generate and send the SMPP request includingthe message and the appropriate delivery policy without any actionsrequired by an operator at the client's site.

A consumer can be an individual or entity associated with a consumerdevice 340, which can be configured to receive messages 316 from one ormore clients 302 via the message delivery system 320. The consumer canhave a particular relationship with the client. For example, theconsumer can be an existing or potential customer of the client orcurrent or potential user of the client's services, amongst others. Insome implementations, the consumer device 340 can be configured toreceive messages via an application 342 operating on the consumer device340. In some implementations, the application 342 is associated with themessage delivery system 320 such that the message delivery system 320 iscapable of sending messages to the consumer device 340 via theapplication 342. In some implementations, the consumer device 340 can beassociated with one or more consumer identifiers that uniquely identifythe consumer to the message delivery system 320. Examples of theconsumer identifier can include one or more of a phone number, a networkdevice identifier, such as a MAC address or a push token identifierassociated with the application 342 operating on the consumer 340.

The consumer device 340 may comprise one or more applications, programs,libraries, services, processes, scripts, tasks or any type and form ofexecutable instructions executing on one or more devices, and can bedesigned, constructed or configured to receive messages from a clientthrough a plurality of delivery channels. For instance, the consumerdevice 340 may include an application operating on the recipientconsumer device 340. The consumer device 340 can be configured toreceive push notifications from the client. In some implementations, theconsumer device 340 can process the received push notifications via anapplication operating on the consumer device. The application 342 can bea native application installed on the consumer device or a web-basedapplication operating through a web-browser of the consumer device. Theapplication can be running in the background of the computing device andcan be configured to alert the consumer of a message received from theclient. The application 342 can include instructions identifying themessage delivery system 320. In some implementations, the application342 can be configured to receive notifications sent from the messagedelivery system via a third-party push notification service. In someimplementations, the message delivery system 320 can include anotification service that can directly send notifications to theconsumer device on which the application is installed. In someimplementations, the message delivery system 320 may deliver the message316 towards the consumer device 340 such that a notification deliveryapplication 342 executing on the consumer device receives the messageand responsive to a consumer delivery policy, presents the notificationon the consumer device 342 as one of a push notification or an instantmessage.

FIG. 3B is a block diagram illustrating a flow of a method fordelivering messages, received via the SMPP protocol, over one of aplurality of delivery channels. In brief overview, the method includesestablishing, by a message deliverer, an SMPP connection with a clientdevice (step 355), receiving a first request to deliver a message to aconsumer device (step 360), identifying, from a delivery policy in thefirst request, a non-SMS delivery channel (step 365) and transmitting asecond request to deliver the message via the non-SMS delivery channel(step 370).

In further detail, the message delivery system can establish an SMPPconnection with a client device (step 355). The SMPP connection isestablished between the message delivery system and the client device.The message delivery system can establish an SMPP connection with aclient agent operating on the client device. In some implementations,the SMPP connection is established with the client device based on SMPPprotocol. In some implementations, the SMPP connection is establishedfor communicating short message service (SMS) messages from the clientdevice to the message delivery system. In some implementations, the SMPPconnection is established for receiving requests from the client deviceto deliver one or more messages to consumer devices to which the messagedelivery system serves as an intermediary. The messages can be deliveredas SMS messages, push messages, instant messages, or in any other formthat can be received by the consumer device. In some implementations,the client agent can send a bind request to open an SMPP session. TheSMPP connection is established over an underlying transport layerconnection between the client agent and the message delivery system. Insome implementations, the message delivery system determines theidentity of the client before establishing a connection with the client.In some implementations, the message delivery system can establish anSMPP connection with one or more clients that subscribe to servicesoffered by the message delivery system. In some implementations, themessage delivery system can maintain a list of clients that subscribe toservices offered by the message delivery system.

In some implementations, the SMPP connection is established by a messagedeliverer configured on a device intermediary between a client deviceand a plurality of consumer devices. In some implementations, themessage deliverer is the message delivery system. In someimplementations, the message deliverer is configured to execute on themessage delivery system. In some implementations, the message deliverysystem includes the message deliverer. In some implementations, at leastone consumer device includes an application operating on the recipientconsumer device. The message deliverer can transmit the message towardsthe consumer device such that a notification delivery applicationexecuting on the consumer device receives the message and responsive toa consumer delivery policy, presents the notification on the consumerdevice as one of a push notification or an instant message. The messagedelivery system can receive a first request to deliver a message to aconsumer device (step 360). The first request can be an SMPP requestfrom the client device. In some implementations, the first request canbe received over the SMPP connection established between the clientdevice and the message delivery system. The first request may bereceived via the SMPP protocol. The first request may be a request todeliver a message to at least one consumer device of the plurality ofconsumer devices. The first request can include a message and a deliverypolicy. The request can include additional information. For instance,the request can identify one or more consumer devices to which todeliver the message, the identity of the client sending the request,among others.

The message can correspond to the information the client would like todeliver to one or more consumers identified in the first request. Thedelivery policy can specify one or more non-SMS delivery channelsthrough which to deliver the message. In some implementations, one ofthe non-SMS delivery channels includes one of a push notificationdelivery channel through which the message is delivered to a consumerdevice as a push notification via an application operating on theconsumer device, or an instant messaging channel through which themessage is delivered to a consumer device as an instant message via aninstant messaging application. The delivery policy can provideinformation indicating one or more target delivery channels throughwhich the message is to be delivered to the one or more consumersidentified in the first request. The delivery policy can also identifythe time at which the message is to be delivered as well include rulesto hold the delivery until one or more triggering events or conditionsoccur. For instance, the delivery policy may specify a triggeringcondition which when triggered, can cause the message to be delivered.

The delivery policy can specify an application executing on the mobiledevice via which to present the message as a notification on theconsumer device. The delivery policy can identify one or more of one ormore consumer devices to which the message is to be delivered, one ormore non-SMS delivery channels according to which the message is to bedelivered, or a time at which the message is to be delivered. Therequest parser of the message delivery system can parse the request toidentify the delivery policy and process the delivery of the messageaccording to the delivery policy. In some implementations, the deliverypolicy is included in the header of the message. In someimplementations, the delivery policy is stored in the message deliverysystem and is specific to the client. In some implementations, thedelivery policy is stored in the message delivery system and is specificto the client-consumer device pair. In some implementations, thedelivery policy is stored in the message delivery system and is specificto the message type. In some implementations, the request can includethe message. The message delivery system can determine the deliverypolicy associated with the request or the message by performing a lookupin a database accessible by the message delivery system to determine anotification policy associated with the message, the client, theconsumer device, or any combination thereof.

The message delivery system can identify, from the delivery policyincluded in or associated with the first request, the non-SMS deliverychannel through which to deliver the message (step 365). The non-SMSdelivery channel may be the delivery channel through which to deliverthe message to the consumer device based on the delivery policy. Thedelivery policy can determine, for one or more consumers, one or morevarious delivery channels through which to deliver the message. In someimplementations, the message deliverer may identify one or more non-SMSdelivery channels. In some implementations, the delivery policy can beincluded in or identified by one or more TLVs of the SMPP request orPDU. The client agent can be configured to generate an SMPP requestusing TLVs that can be understood and processed by the message deliverysystem. The message delivery system can identify the delivery policy anddetermine one or more delivery channels through which to deliver themessage to each of the consumers the SMPP request identifies as arecipient consumer. In some implementations, the message delivery systemcan further inspect a header of the first request, identify fields ofthe header of the first request, and determine from values of theidentified fields, the delivery policy according to which to deliver themessage.

The message delivery system can generate and transmit a second requestto deliver the message via the non-SMS delivery channel (step 370). Thesecond request can include the message and instructions for deliveringthe message to the recipient consumer device. In some implementations,the message delivery system transmits a second request to deliver themessage via one or more non-SMS delivery channels. In someimplementations, if the delivery channel through which the message is tobe delivered is an SMS channel, the SMS manager can be configured togenerate an SMS message and transmit the SMS message towards therecipient consumer device. The SMS message can include the messageincluded in the SMPP request from the client. In some implementations,the message delivery system can send the SMS message to the consumerdevice via an SMSC configured to process the SMS message. In some suchimplementations, the message delivery system can establish an SMPPconnection with the SMSC through which the SMS message can betransmitted. The SMSC can then deliver the SMS message to the intendedrecipient consumer. In some implementations, if the delivery channelthrough which the message is to be delivered is a push notificationchannel, the notification manager can be configured to generate a pushnotification request and transmit the push notification request towardsthe recipient consumer device. The push notification request can includethe message to be delivered. In some implementations, the notificationmanager can deliver the push notification request to the consumer via athird-party push notification service. The third-party push notificationservice can be configured to transmit the message included in the secondrequest to the consumer device for presentation via an applicationexecuting on the client device. The application can be specific to theclient device. The push notification request can include the message tobe delivered as well as a device token identifying the consumer deviceto which the message is to be delivered. In some implementations, thenotification manager of the message delivery system can transmit a pushnotification request directly to the consumer device as long as theconsumer device maintains a secure connection with the message deliverysystem over which the push notification request can be sent. In someimplementations, the message delivery system can transmit, for a firstnon-SMS delivery channel, a corresponding second request to a firstentity configured to transmit the message to the consumer device via thefirst non-SMS delivery channel. The message delivery system may alsotransmit, for a second non-SMS delivery channel, another correspondingsecond request to a second entity configured to transmit the message tothe consumer device via the second non-SMS delivery channel. Forinstance, the message delivery system may transmit the message to afirst entity to deliver the message via a push notification channel andtransmit the message to a second entity to deliver the message via aninstant messaging delivery channel.

D. Systems and Methods for Delivering Communications via an ApplicationProvider Proxy

Various embodiments disclosed herein are directed to methods and systemsfor delivering communications to one or more consumer devices via anapplication provider proxy. In some implementations, the applicationprovider proxy can be the same as or similar to a message deliverysystem, such as the message delivery system 320 depicted in FIG. 3A. Theapplication provider proxy can communicate with a notification deliveryapplication installed and/or executing on one or more consumer devices.The notification delivery application can be configured to receive thepush notifications and take one or more actions responsive to the pushnotifications. In some implementations, the notification deliveryapplication can be configured to present the notifications at theconsumer device in accordance with a consumer notification policy. Theconsumer notification policy can include one or more rules specifyingthe manner in which notifications can be presented. The application canbe configured to take one or more actions responsive to presenting thenotification. In some implementations, the application can be configuredto take one or more actions responsive to presenting the notification atthe consumer device and receiving a response from a consumer of theconsumer device.

The application provider proxy can be configured to receive requests todeliver notifications to one or more consumer devices. The notificationscan include messages that were included in the requests received by theapplication provider proxy. In some implementations, the requests can bereceived from one or more clients authorized to communicate withconsumers to which the clients wish to send notifications. In someimplementations, the application provider proxy can be configured tocommunicate with a message delivery application installed on a consumerdevice to which the notification is to be delivered. In someimplementations, the application provider proxy may utilize the servicesof a third-party push notification service configured to deliver pushnotifications to the consumer device.

The message delivery application installed on the consumer device canreceive a notification from the application provider proxy and executeone or more instructions responsive to receiving the notification. Insome implementations, the message delivery application can be configuredto perform one or more actions in response to a user of the consumerdevice taking an action in response to the notification received by theconsumer device. These actions can correspond to opening a web browserand accessing a web page, opening a third-party application, amongstothers.

In some implementations, the application provider proxy may delivernotifications in accordance with a consumer notification policy. Theconsumer notification policy can include one or more rules identifying adelivery channel through which to deliver the notification, conditionsin which to hold the notification and conditions in which to release thenotification for presentation, the manner in which the notification isto be presented on the consumer device, amongst others.

FIG. 4A is a block diagram illustrating a computer networked environmentfor delivering communications via an application provider proxy. Theenvironment includes an application provider proxy 420 configured toserve as a proxy to an application provider. The application providercan provide an application for executing on a consumer device and theapplication provider proxy can serve as the proxy to the applicationprovider such that notifications to be delivered to the applicationexecuting on the consumer device are provided by the applicationprovider proxy. The application provider proxy 420 can sendcommunications to one or more consumer devices 440 over one or morenetworks, such as the network 104. In some implementations, theapplication provider proxy 420 can be configured to communicate with oneor more clients 410, such as via agent 412. The clients can send to theapplication provider proxy 420, one or more requests to delivercommunications to the consumer devices 440. In some implementations, theconsumer devices 440 may be associated with one or more consumers whomay be past, existing or future customers, members, subscribers or usersof the clients or the clients' services.

The client 410 can include an agent 412 that is configured to establishcommunications between the client 410 and the application provider proxy420. In some implementations, the agent 412 can be the same or similarto the agent 312 described with respect to FIG. 3A.

The client 410, via the client agent 412, can be configured to generateand transmit a request 414 to deliver communications to one or moreconsumers. The client 410 can be configured to transmit the request 414to the application provider proxy 420, which is configured to processthe request 414 and deliver the communications 434 to the consumersintended by the client. Client agent 412 may comprise one or moreapplications, programs, libraries, services, processes, scripts, tasksor any type and form of executable instructions executing on one or moredevices, and can be designed, constructed or configured to performvarious functions associated with generating and transmitting a requestto deliver communications to one or more consumers. In someimplementations, the client 410 and the application provider proxy 420can communicate via a communication path 416. In some implementations,the client agent 412 is configured to establish a connection with theapplication provider proxy 420. In some implementations, the clientagent 412 is configured to establish an application layer protocolconnection with the application provider proxy 420. In someimplementations, the client agent 412 is configured to establish an SMPPprotocol connection with the application provider proxy 420. In someimplementations, the client agent 412 can communicate with theapplication provider proxy via a connectionless protocol.

The client agent 412 can be configured to present a user interfacethrough which an operator associated with the client 410 can interactwith the client agent 412. In some implementations, the user interfacecan be configured to allow an operator at the client 410 to create arequest to deliver communications to one or more consumers. The userinterface can provide options for selecting the delivery channel throughwhich a communication is to be delivered, the time at which it is to bedelivered, one or more conditions or triggering events upon which thecommunication is to be delivered, other particular delivery instructionsincluding whether to request a read receipt delivery receipt responses,amongst others.

In some implementations, the client agent 412 can be configured to haveone or more predefined rules for generating requests. These rules can bebased on one or more triggering events. For example, using the exampleof a bank wishing to deliver messages to its customers, a client agentof the bank can be configured to monitor the bank accounts of the bank'scustomers. The client agent 412 can further be configured to monitor fora triggering event, such as a bank account balance falling below apredefined threshold value, for example, $200. The client agent canfurther be configured to automatically generate a request including acommunication alerting the customer that their bank account balance hasfallen below $200. Moreover, the client agent 412 can be configured toinclude a delivery policy that may be specific to the customer or may bespecific to the type of communication indicating the manner in which todeliver the message to the customer. The client agent 412 can beconfigured to generate and send the communication and the appropriatedelivery policy without any actions required by an operator at theclient's site.

The application provider proxy 420 may execute on one or more servers,such as the server 106 shown in FIG. 1A. The application provider proxy420, and any modules or components thereof, may comprise one or moreapplications, programs, libraries, services, processes, scripts, tasksor any type and form of executable instructions executing on one or moredevices, such as servers. The application provider proxy 420, and anymodules or components thereof, may use any type and form of database forstorage and retrieval of data. The application provider proxy 420 maycomprise function, logic and operations to perform any of the methodsdescribed herein.

In some implementations, the application provider proxy 420 can beconfigured to establish a connection 416 with one or more clients 410through which the clients can send one or more requests 414 to delivercommunications to one or more consumer devices 440. In someimplementations, the application provider proxy 420 can establish theconnection 416 with the client agent 412 operating on the client 410.

The application provider proxy 420 can be configured to delivercommunications 434 that can include one or more notifications 436 to theconsumer devices 440 via one or more delivery channels 418 between theapplication provider proxy 420 and the consumer device 440. In someimplementations, the application provider proxy 420 can include a pushnotification service 428 configured to deliver push notifications to oneor more applications operating on the consumer devices 440. In someimplementations, the push notification service 428 can operate as or ona standalone entity in communication with the application provider proxy420 but configured to deliver push notifications to one or moreapplications operating on the consumer device 440. In someimplementations, the application provider proxy 420 may employ theservices of an intermediary to deliver the communications 434 to theconsumer devices 440. The intermediary can be a short message servicecenter (SMSC) in situations where the communication 434 is to bedelivered as an SMS message. The intermediary can be a third-party pushnotification service 452, for example, Apple Push Notification Service(APNS) or Google Cloud Messaging (GCM), in situations where thecommunications 434 is to be delivered as a push notification.

In some implementations, the application provider proxy 420 can be astandalone entity intermediary to the clients 410 and the consumers 440.In some implementations, the application provider proxy 420 can operateon a client 410. In some implementations, the application provider proxy420 can operate on an entity intermediary to a client and the consumers,for example, on an aggregator, such as the aggregator 204 shown in FIGS.2A and 2B, an SMSC or a push notification service, such as thethird-party push notification service 452.

The application provider proxy 420 can include a client request parser422, a communication delivery manager 426, a monitoring agent 424, apush notification service 428, a consumer notification policy manager430 and one or more content repositories. The content repositories caninclude a notification log configured to store one or more notifications436 delivered to the consumer devices, a client delivery policy databaseconfigured to one or more delivery policies 402, and a consumernotification policy database configured to store one or more consumernotification policies 404. In some implementations, the contentrepositories 432 can include a database that stores device tokens 438corresponding to the consumer devices 440 to which notifications 436 canbe delivered. The application provider proxy 420 can also include one ormore additional modules configured to facilitate the delivery ofcommunications across one or more delivery channels 418, for example, apush notification channel, an SMS channel, an email channel, a socialnetworking application channel, an instant messaging channel, amongothers.

The client request parser 422 may comprise one or more applications,programs, libraries, services, processes, scripts, tasks or any type andform of executable instructions executing on one or more devices, andcan be designed, constructed or configured to receive one or morerequests from one or more clients 410 with which the applicationprovider proxy 420 can establish connections. The request 414 caninclude a request to send a communication 434 to one or more consumerdevices 440. The request 414 can be sent from the client 410 in responseto a triggering event. The triggering event can be any event oroccurrence for which the client 410 wishes to send a communication toone or more consumer devices 440. The client request parser 422 can beconfigured to parse the received client request 414. The client requestparser 422 can identify one or more intended recipients to which todeliver a communication 434 in response to the received request 414.

In some implementations, the client request parser 422 can also identifya delivery policy 402 associated with the request 414. In someimplementations, the request 414 can include the delivery policy 402according to which a communication 434 is to be delivered to theconsumer device 440. In some implementations, the client request parser422 can maintain one or more delivery policies 402 associated withclients sending the request 414. In some implementations, the deliverypolicy 402 can be specific to a particular client 410 such that onlyrequests received from a particular client can be handled according tothe delivery policy 402. In some other implementations, the deliverypolicy 402 can be common to a plurality of clients such that requestsreceived from more than one client can be handled according to the samedelivery policy 402.

The client request parser 422 can identify a delivery policy 402according to which a communication 434 based on the request 414 is to bedelivered to one or more consumer devices 440 from the request 414itself or from settings associated with the client 410 sending therequest 414. In some implementations, the client request parser 422 cananalyze the contents of the request 414 to identify the delivery policy402.

In some implementations, the client request parser 422 can identify adelivery policy 402 according to which the communication 434 to theconsumer devices 440 is to be delivered. In some implementations, theclient request parser 422 can identify the delivery policy 402 based onthe type of communication 434 to be delivered or the type of request 414received. In some implementations, the client request parser 422 canidentify the delivery policy 402 for delivering a communication 434 tothe one or more intended consumer devices 440 based on the type,identity or number of consumer devices 440 to which the communication isto be delivered.

A delivery policy 402 can include one or more rules for delivering acommunication associated with the received request, including but notlimited to identifying one or more target delivery channels throughwhich to deliver the communication, identifying a time at which todeliver the communication, identifying one or more conditions fordelivering the communication, for example, a condition requiring thatthe consumer device be located within a particular geographic region,amongst other conditions or rules.

In some implementations, the delivery policy 402 can include one or morerules for determining when to deliver a communication. In someimplementations, the rules can specify to deliver a communication uponthe occurrence of a triggering event. The event can be associated withthe one or more consumer devices 440 to which the communication isintended to be delivered or an event unrelated to the consumer devices440. An example of an event associated with a consumer device caninclude the consumer device being located within a predefined geographicarea. An example of an event unrelated to the consumer devices 440 canbe a weather related event, for example, it's raining at a particularlocation, or a holiday related event, for example, it's Christmas day.

In some implementations, the client request parser 422 can also beconfigured to send responses to the client 410 in response to receivingthe request 414. In some implementations, the client request parser 422can send a response to the client in response to processing the request414. In some implementations, the client request parser 422 can send aresponse to the client 410 in response to receiving confirmation thatthe request was successfully processed. In some implementations, therequest is successfully processed upon successfully delivering acommunication to the consumer device 440. In some implementations, therequest 414 is successfully processed upon receiving confirmation thatthe communication was successfully delivered to the consumer device. Insome implementations, the request 414 is successfully processed when anotification 436 has been released for viewing on the consumer device.In some implementations, the notifications 436 may be delivered to theconsumer device 440 but not released for presentation until later. Aswill be described below, the notification or other communications may bereleased for presentation on the consumer device 440 upon one or moreconditions of a consumer notification policy 404 being met.

Generally, the consumer notification policy 404 can include one or morerules identifying a delivery channel through which to deliver thenotification, conditions in which to hold the notification andconditions in which to release the notification for presentation, themanner in which the notification is to be presented on the consumerdevice, amongst others.

In some implementations, the consumer notification policy 404 and thedelivery policy 402 can both include one or more rules for delivering acommunication, including but not limited to identifying one or moretarget delivery channels through which to deliver the communication,identifying a time at which to deliver the communication, identifyingone or more conditions for delivering the communication, for example, acondition requiring that the consumer device be located within aparticular geographic region, amongst other conditions or rules. In someimplementations, the basic distinction between the consumer notificationpolicy 404 and the delivery policy 402 is that the consumer notificationpolicy is specific to a consumer device 440 or may be specified by aconsumer associated with the consumer device. Conversely, the deliverypolicy can be specific to a particular client or may be specified by aclient 410 of the application provider proxy 420.

In some implementations, the consumer notification policy 404 can applyto one or more communications received by the consumer device 440 fromthe application provider proxy 420. The consumer notification policy canrelate to one or more of delivering communications, handlingnotifications, presenting notifications, amongst others. The consumernotification policy may specify the delivery channel via which acommunication is to be delivered. For example, the consumer notificationpolicy can specify that a communication is to be delivered via SMS ifthe Wi-Fi component of the communication device is switched off or acommunication is to be delivered via push notification if the Wi-Ficomponent of the communication device is switched on.

The consumer notification policy 404 can include one or more rules orconditions for holding notifications. In some implementations, theconsumer notification policy 404 can include one or more rules orconditions for holding notifications at the application provider proxy420 or at the consumer device 440. The notifications 436 may be helduntil the conditions for releasing the notification 436 have beensatisfied. In some implementations, these conditions can be based oninformation received from the consumer device 440 or the applicationprovider proxy 420. In some implementations in which the notificationsare held at the consumer device 440, the application provider proxy 420may send one or more instructions to release notifications forpresentation by communicating with the notification delivery applicationof the consumer device.

The consumer notification policy 404 can include one or more rules forreleasing the notifications 436 for presentation on the consumer device440. In some implementations, these rules may be based on one or moreconditions, events or settings related to the consumer or the consumerdevice. For instance, push notifications received by the consumer device440 may be held until one or more conditions are met. Examples ofconditions can be based on location, time, third-party sourceinformation, amongst others. For example, the consumer notificationpolicy 404 may include a rule to hold notifications between the hours of12:30 pm and 2 pm. Another consumer notification policy may include arule to hold notifications while the consumer device is determined to bein Europe.

In some implementations, the consumer notification policy 404 caninclude one or more rules that may apply a particular consumernotification policy to every notification from the application providerproxy 420 or a subset of the notifications from the application providerproxy 420. In some implementations, the consumer notification policy 404can be specific to a particular notification, a particular notificationtype, notifications received within a particular time period,notifications generated in response to specific client requests, amongstothers. In some implementations, the consumer notification policy 404can be specific to notifications related to particular types ofinformation, for example, bank account information, health relatedinformation or social media information. In some implementations, theconsumer notification policy 404 can be specific to notificationsrelated to a particular client or client type, for example, social mediaclients, finance related clients, retail clients, amongst others.

The consumer notification policy 404 can include one or more rulesindicating the manner in which to present the notifications. Forexample, a notification can be presented in one or more ways, includingbut not limited to playing a sound, generating a vibration, presenting avisual notification on the screen, or any combination thereof. In someimplementations, the consumer notification policy 404 can identify thetype of sound to play the type of vibration to generate and the type ofvisual notification to provide. In some implementations, the consumernotification policy 404 can include one or more rules that are specificto a particular client, request type, consumer device state, consumerdevice location, time of day, current phone settings, amongst others.

In some implementations, a monitoring agent 424 may operate on theapplication provider proxy 420 and can determine that a triggering eventhas occurred. In some implementations, the monitoring agent 424 can be aprogram, script, application or other software construct can beconfigured to monitor or track activities on behalf of one or moreclients 410 and can be configured to determine if a triggering event hasoccurred. In some such implementations, the monitoring agent 424 canserve as a client agent specific to a particular client. In someimplementations, the monitoring agent 424 can be an agent that monitorsactivities associated with more than one client. In someimplementations, the monitoring agent 424 can be configured to monitordatabases, records, files, transactions or other information of one ormore clients to determine that a triggering event has occurred. In somesuch implementations, the client has authorized the monitoring agent 424of the application provider proxy 420 access to such information.

In implementations that utilize a monitoring agent, the applicationprovider proxy 420 can be configured to generate and delivercommunications to one or more consumer devices 440 without having toreceive a request, such as the request 414 or other instructions from aclient, such as the client 410. In some implementations, the applicationprovider proxy 420 may be authorized to take such actions on behalf ofthe clients responsive to predetermined events whose occurrence isdetected by the monitoring agent 424. In some such implementations, theapplication provider proxy 420 can receive a policy from a client thatmay identify the role of the application provider proxy 420 and themonitoring agent 424, provide authorization to monitor or trackinformation associated with the client and include one or moreconditions upon which the application provider proxy 420 can deliver acommunication to the consumer devices 440 on behalf of the client 410.The authorization can include authorization to access secureconfidential databases, servers and other records of the client.

The communication delivery manager 426 may comprise one or moreapplications, programs, libraries, services, processes, scripts, tasksor any type and form of executable instructions executing on one or moredevices, and can be designed, constructed or configured to delivercommunications 434 to the consumer device 440 over one or more deliverychannels 418. In some implementations the communication delivery manager426 can be configured to generate and deliver communications to theconsumer devices responsive to the application provider proxy 420receiving a request, such as the request 414 from a client. In someimplementations, the communication delivery manager 426 can beconfigured to generate and deliver communications to the consumerdevices in response to the application provider proxy 420 determiningthat a triggering event has occurred, which warrants the applicationprovider proxy 420 to deliver one or more communications to one or moreconsumer devices 440.

The communication delivery manager 426 can be configured to generate thecommunications 434 to be delivered to one or more consumer devices. Thecommunication 434 can include a notification 436 to be delivered to theconsumer device 440. The notification can be an SMS message, a pushnotification, an email, a social networking post, a tweet, an instantmessage or any other type of communication that can be received at theconsumer device.

The communication delivery manager 426 can be configured to generate acommunication based on one or more of the delivery policy 402 of theclient 410, the consumer notification policy 404 associated with aparticular consumer associated with a consumer device 440 to which thecommunication 434 is to be delivered and the type of communication to bedelivered. The communication 434 can include information needed todeliver the communication 434 to the intended consumer device 440 and anotification 436. The information can include a consumer deviceidentifier, such as a token, a phone number, an email address associatedwith an email account of the consumer of the consumer device 440, aninstant messaging identifier associated with an instant messagingaccount of the consumer of the consumer device 440, a social networkingprofile identifier associated with a social networking account of theconsumer of the consumer device 440, amongst others.

The notification 436 included in the communication 436 can be an SMSmessage, an email message, a social networking post, a tweet, or anyother type of notice, message or notification. In some implementations,the notification 436 can be a push notification. The push notificationcan be directed towards a consumer device 440 and may identify aparticular application installed on the consumer device. In someimplementations, the push notification 436 can include a payload and adevice token 438. In some implementations, the payload can be aJSON-defined property list that specifies how the consumer associatedwith the consumer device 440 is to be alerted. The payload can includean alert message to display on the consumer device and a graphical iconof the application, an identifier identifying an icon associated withthe application or a graphical icon associated with the clientrequesting to deliver the notification. In some implementations, thepayload can include additional information that can be used by theapplication to which the notification is directed to take additionalactions. For example, the payload can include information that can beused to identify a sound to play when the notification is received,amongst others.

In some implementations, the device token 438 can contain informationthat enables the push notification service to locate the consumer deviceto which to deliver the notification and can be used to authenticate therouting of the notification. The device token 438 can be issued by thepush notification service delivering the notification. To deliver pushnotifications to the consumer device, the application provider proxy candeliver the communications by including the device token 438 along witheach notification to be delivered. In some implementations, the devicetoken 438 can be the basis for establishing trust that the routing of aparticular notification is legitimate.

In some implementations, the application provider proxy 420 can onlypush notifications to a particular application installed on the consumerdevice 440. The particular application can act as an agent of theapplication provider proxy 420 and can be configured to receive the pushnotifications from the application provider proxy 420. An example of theparticular application is the notification delivery application 442installed on the consumer device 440, details of which are providedbelow. In some implementations, the device token 438 issued by the pushnotification service 428 or the third-party notification service 452 maybe unique to the particular application of the consumer device 440. Thedevice token 438 can be an opaque identifier of a consumer device that anotification service, such as notification service 428 or 452 gives to aconsumer device 440 when the notification service first connects withconsumer device 440. The consumer device 440 can then share the devicetoken 438 with the notification delivery application 442 installed onthe consumer device 440. The notification delivery application 442 canthen share the device token 438 with the application provider proxy 420.

In some implementations in which the push notification service 428 canbe a part of the application provider proxy 420, the push notificationservice 428 can make the device token 438 accessible to the applicationprovider proxy 420, for example, by storing the device token 438 in thecontent repository 432 or providing it to the application provider proxy420. In some implementations in which the push notification service is athird-party push notification service 452, the application providerproxy 420 can be configured to receive the device token 438 associatedwith the consumer device 440 from the consumer device 440. In someapplications, for the application provider proxy 420 to sendnotifications to the consumer device 440, the application provider proxy420 may include the device token 438 issued to the notification deliveryapplication 442 along with each notification.

The push notification service 428 may comprise one or more applications,programs, libraries, services, processes, scripts, tasks or any type andform of executable instructions executing on one or more devices, andcan be designed, constructed or configured to deliver communicationsthat include push notifications to the notification delivery application442 of the consumer device 440. The push notification service 428 can beconfigured to establish a secure delivery channel with the notificationdelivery application 442 through which the communications can bedelivered. The notification delivery application 442 can be installed onthe consumer device 440 and include instructions that configure thenotification delivery application 442 to receive communications from thepush notification service 428. When the notification deliveryapplication 442 is installed on the consumer device, the pushnotification service 428 can assign the notification deliveryapplication a device token that is unique to the notification deliveryapplication installed on the consumer device. In this way, the devicetoken can be used to uniquely route communications to the notificationdelivery application installed on a particular consumer device.

In some implementations in which the client requesting to deliver acommunication to a consumer device has an applicable delivery policy 402and the consumer device 440 intended to receive the communication has anapplicable consumer notification policy, the application provider proxy420 may be configured to implement both the delivery policy 402 and theconsumer notification policy 404 to the extent that the policies do notcontradict one another. If one or more conditions of the delivery policy402 and the consumer notification policy 404 do contradict one another,the condition of the consumer notification policy 404 contradictory tothe condition of the delivery policy 402 may override the condition ofthe delivery policy 402 for that particular consumer device. In someimplementations, however, the condition of the delivery policy 402contradictory to the condition of the consumer notification policy 404may override the condition of the delivery policy 402. Thisdetermination can be made by the communication delivery manager 426.

In some implementations, the communication delivery manager 426 can beconfigured to deliver push notifications to one or more consumer devices440 without considering the consumer notification policy 404 associatedwith the consumer device 440 to which the notifications 436 are beingdelivered. In some such implementations, the consumer device 440, viathe notification delivery application 442 installed thereon, can beconfigured to manage the holding, releasing and presentation of thenotifications in accordance with the consumer notification policies 404associated with the consumer device.

In some implementations, the communication delivery manager 426 can beconfigured to deliver a push notification to a consumer device inaccordance with the consumer notification policy 404 associated withconsumer device 440 to which the push notifications is being delivered.

The consumer device 440 can be configured to generate or create aconsumer notification policy 404. A consumer, via the consumer device440, can create, modify or delete one or more consumer notificationpolicies 404 and can also determine priority levels of one or more ofthe consumer notification policies 404. In some implementations, theconsumer can set one or more rules according to which a particularconsumer notification policy can be implemented. The consumer mayinteract with the notification delivery application via the consumerdevice to create, modify or delete the consumer notification policies404.

The push notification service 428 can be configured to deliver pushnotifications in response to a consumer notification policy 404 of theconsumer device to which the push notifications are being delivered. Insome implementations, the communication delivery manager 426 can beconfigured to work with the push notification service 428 to deliver thepush notifications to the consumer device.

In some implementations, the application provider proxy 420 can beconfigured to send notifications via a third-party notification service452. The third-party notification service 452 can be a short messageservice center (SMSC), an email server or exchange, an instant messagingserver or a third-party push notification service, for example, ApplePush Notification Service (APNS) or Google Cloud Messaging (GCM).

The consumer notification policy manager 428 may comprise one or moreapplications, programs, libraries, services, processes, scripts, tasksor any type and form of executable instructions executing on one or moredevices, and can be designed, constructed or configured to manage theconsumer notification policies 404 associated with the consumer devices.In some implementations, the consumer notification policy manager 428can manage consumer notification policies 404 of consumer devices onwhich the notification delivery application 442 is installed. Theconsumers can create, modify or delete their consumer notificationpolicies 404 via the notification delivery application.

The consumer notification policy manager 430 can be configured to storethe consumer notification policies 404 in storage of the applicationprovider proxy or on a memory accessible by the application providerproxy. In some implementations, the consumer notification policies 404can be stored in a content repository, such as the content repository432.

The consumer notification policy manager 430 can be configured toprovide one or more consumer notification policies 404 to thecommunication delivery manager. In some implementations, the consumernotification policy manager 430 can determine which consumernotification policy to implement for a particular request. In someimplementations, the consumer notification policy manager 430 canidentify the request for which the notification is being generated anddetermine, for example, one or more of the client associated with therequest, the type of request, the contents of the request or informationassociated with the consumer device, such as the consumer device'scurrent location, time, or other information received from third-partyservices operating on the consumer device. The consumer notificationpolicy manager can then determine which consumer notification policy toimplement based on the determination. In some implementations, thecommunication delivery manager 426 or the notification deliveryapplication 424 may perform one or more of the functions performed bythe consumer notification policy manager 430.

The application provider proxy 420 may be designed, constructed and/orconfigured to communicate with and/or interface to a plurality ofdifferent content repositories, such as the content repository 432. Thecontent repository 432 can be configured to store one or more deliverypolicies 402 and consumer notification policies 404.

In some embodiments, the application provider proxy 420 can communicatewith the content repositories over one or more networks 104, such as toa remote server or cloud storage service. The content repositories mayinclude any type and form of storage or storage service for storing datasuch as digital content. Examples of such content repositories includeservers or services provided by Dropbox, Box.com, Google, amongstothers. In some embodiments, the content repositories are located localto the application provider proxy 420. In some embodiments, the contentrepositories are maintained by the application provider proxy 420.

In some implementations, the content repositories can store content,including information associated with one or more clients and one ormore consumers. A content repository, for example, a client contentrepository can include information associated with one or more clients,including client information, information relating to a connectionbetween the client and the application provider proxy 420, a consumerlist of the client identifying one or more consumers to which the clientmay communicate, client preferences, one or more client notificationdelivery policies, as well as a record of any messages received from ordelivered to the client. Another content repository, for example, aconsumer profile database can be configured to maintain consumerprofiles for one or more consumers associated with one or more clients.The consumer profiles can include information related to notificationchannels associated with the consumers, preferences of the consumer,tokens associated with any push notification services through which pushnotifications are to be delivered to the consumer, telephone numbers,amongst others.

The consumer device 440 may comprise one or more applications, programs,libraries, services, processes, scripts, tasks or any type and form ofexecutable instructions executing on one or more devices, and can bedesigned, constructed or configured to receive messages from a clientthrough a plurality of delivery channels. The consumer device 440 can beconfigured to receive communications from the application providerproxy. The communications can be received one or more delivery channels,including but not limited to SMS, push notifications, email, instantmessaging, social networking posts, tweets, amongst others. As describedabove, in some implementations, the delivery channel via which theconsumer device can receive communications can be based in part on adelivery policy of the client or a consumer notification policy 404.

The consumer device 440 can be configured to include the notificationdelivery application 442. The consumer device 440 can also be configuredto utilize, execute or include one or more services, such as third partyservices 444, a location service 446, a time service 448, amongstothers. In some implementations, the consumer device 440 can beconfigured to include one or more applications 450 a-450 n.

In some implementations, the consumer device 440 can process thereceived push notifications via the notification delivery application442 operating on the consumer device 440. The notification deliveryapplication 442 can be a native application installed on the consumerdevice or a web-based application operating through a web-browser of theconsumer device. The notification delivery application 442 can berunning in the background of the computing device and can be configuredto alert the consumer of a notification received from the client 410 viathe application provider proxy 420. The notification deliveryapplication 442 can include instructions identifying the applicationprovider proxy 420. In some implementations, the notification deliveryapplication 442 can be configured to receive notifications sent from theapplication provider proxy 420 via a third-party push notificationservice. In some implementations, the application provider proxy 420 caninclude a notification service that can directly send notifications tothe consumer device on which the notification delivery application 442is installed.

The notification delivery application 442 may comprise one or morelibraries, services, processes, scripts, tasks or any type and form ofexecutable instructions executing on the consumer device on which thenotification delivery application 442 is installed, and can be designed,constructed or configured to manage the processing and handling of oneor more notifications 436 and one or more consumer notification policies404. The notification delivery application 442 can be configured toreceive push notifications from the application provider proxy via oneor more delivery channels 418. In some implementations, the notificationdelivery application 442 can be configured to process the received pushnotifications according to one or more consumer notification policies404 of the consumer device or the notification delivery application 442installed on the consumer device. In some implementations, the consumermay be able to select one or more consumer notification policies 404 tobe implemented for handling notifications. In some implementations, theconsumer may select one or more consumer notification policies 404 to beimplemented for handling certain notification types.

In some implementations, the notification delivery application 442 canprocess the push notifications by identifying one or more consumernotification policies 404 applicable to the push notification,determining that the conditions of the consumer notification policies404 have been met, and releasing the notifications for presentation onthe consumer device upon determining that the conditions have been met.In some implementations, the notification delivery application 442 canbe configured to hold the notifications in a notification queue. In someimplementations, the notification delivery application 442 can beconfigured to release notifications from the queue as the conditions ofthe consumer notification policy applicable to the notification are met.In some implementations, the notification delivery application 442 canrelease the push notifications for presentation on the consumer device.In some implementations, the push notifications can be presented bydisplaying a notification on the display screen of the consumer device,by playing a sound or generating a vibration. In some implementations,the push notifications can be presented by launching an application.

In some implementations, the notification delivery application 442 canbe configured to take additional actions in response to identifying anaction taken on the notification being presented. For example, thenotification delivery application 442 may identify that the notificationhas been selected. In some implementations, upon identifying that anaction has been taken, the notification delivery application 442 can beconfigured to perform one or more actions. Examples of the actions caninclude launching an application, launching a browser, directing thebrowser to a particular web page, accessing one or more services,amongst others.

In some implementations, the notification delivery application 442 canbe configured to perform one or more actions by receiving additionalinformation from the application provider proxy 420. In someimplementations, the notification delivery application 442 can beconfigured to make an API call or pull information from the applicationprovider proxy 420. In some implementations, the application providerproxy 420 can provide further instructions to the notification deliveryapplication 442 via a separate delivery channel upon receiving a pullrequest from the notification delivery application 442. The instructionscan include one or more actions to take by the notification deliveryapplication 442. In some implementations, the actions can be taken bythe notification delivery application 442 in response to identifying anaction has been taken in response to the notification being presented.

In some implementations, the notification delivery application 442 canidentify one or more consumer notification policies 404 applicable tothe push notification by identifying the content of the pushnotification. In some implementations, the content of the pushnotification can include or identify the client associated with the pushnotification, the type of notification, the purpose of the notificationand the actions that will be performed by the consumer device inresponse to processing the push notification. Examples of the actionsthat can be performed can include launching a third-party application,launching a browser, launching a media player, launching one or moreservices of the consumer device, amongst others. The applications 450a-450 n can be applications installed on the consumer device and may bethird-party applications. In some implementations, these applicationsmay be associated with one or more of the clients from which requestsare received by the application provider proxy 420. In some suchimplementations, the notifications can be configured to launch anapplication of the client with which the notification is associated. Insome implementations, the notifications can be configured to launch oneof the applications 450 a-450 n. In some implementations, theapplication can be a browser through which a consumer can access theinternet. In some implementations, the notifications can be configuredto launch a browser application and go to a specific web page.

A consumer can be an individual or entity associated with a consumerdevice 340, which can be configured to receive communications 434 fromthe application provider proxy 420. The consumer can have a particularrelationship with the client. For example, the consumer can be anexisting or potential customer of the client or current or potentialuser of the client's services, amongst others. In some implementations,the consumer device 440 can be configured to receive messages via anotification delivery application 442 operating on the consumer device440. In some implementations, the notification delivery application 442is associated with the application provider proxy 420 such that theapplication provider proxy 420 is capable of sending communications tothe consumer device 440 via the notification delivery application 442.In some implementations, the consumer device 440 can be associated withone or more consumer identifiers that uniquely identify the consumer tothe application provider proxy 420. Examples of the consumer identifiercan include one or more of a phone number, a network device identifier,such as a MAC address or a push token identifier associated with thenotification delivery application 442 operating on the consumer device340.

FIG. 4B is a block diagram illustrating a flow of a method fordelivering communications via an application provider proxy. In briefoverview, the method includes receiving, by a notification manager, froma client device, a notification to be delivered to an applicationexecuting on a consumer device (step 455), holding, by the notificationmanager, the notification in a notification queue (step 460),identifying, by the notification manager, a consumer notification policyof the consumer device applicable to the notification, the consumernotification policy specifying one or more conditions for presenting thenotification at the consumer device (step 465), and releasing, by thenotification manager, from the notification queue, the notification forpresentation at the consumer device upon determining that the conditionsof the consumer notification policy have been met (step 470).

In further detail, the notification manager, receives, from a clientdevice, a notification to be delivered to an application executing on aconsumer device (step 455). In some implementations, the notificationmanager is configured on a device intermediary to the client device anda plurality of consumer devices including the consumer device. In someimplementations, the notification manager is configured on theapplication provider proxy. In some implementations, the notificationmanager is configured on the consumer device. In some implementations,the notification manager can be executing on both the applicationprovider proxy and on each of the consumer devices to which thenotification manager can deliver notifications.

In some implementations in which the notification manager is executingon the application provider proxy, the application provider proxy andthe client device can communicate over an SMPP connection establishedbetween the application provider proxy and the client device. The clientdevice can transmit a request to the notification manager to deliver anotification to one or more consumer devices. In some implementations,the request can identify a delivery policy according to which to deliverthe notification to the consumer devices. In some implementations, thenotification manager can receive the request and identify one or moreconsumer devices to which to send the notification.

In some implementations, the client device can generate and transmit therequest to deliver the notification responsive the occurrence of anevent or condition. In some implementations, the notification managercan receive a notification to be delivered to an application executingon the consumer device responsive to identifying the occurrence of anevent or condition. In some implementations, the occurrence of an eventcan include receiving a request from a client requesting to send acommunication to the consumer device. In some such implementations, theclient can send a request to the notification manager to deliver anotification to a consumer device. In some implementations, the clientdevice can transmit the request via the client agent of the clientdevice. In some implementations, the notification manager can identifyan occurrence of an event by monitoring activities at or related to aparticular client device and detecting that a triggering event hasoccurred. In some such implementations, the notification manager mayneed authorization to monitor activities at or related to the particularclient. In some implementations, the notification manager can identifythe occurrence of an event based on one or more third-party sources, forexample, a weather source. In one example, the notification manager canidentify that a hurricane is approaching a particular geographic area.This can be an event for which a notification can be delivered toconsumer devices in the particular geographic area to seek shelter as ahurricane is approaching. In one specific example, the notificationmanager can either receive a request from a client to notify a consumerof a low account balance via a push notification. The notificationmanager can determine the identity of the consumer and/or an associatedconsumer device of the consumer to which to deliver a push notification.

The notification manager holds the notification in a notification queue(step 460). In some implementations, the notification can be held in thenotification database or stored in a notification queue. In someimplementations, the notification manager executing on the applicationprovider proxy can store the notifications in a data store of theapplication provider proxy. In some implementations in which thenotification manager is executing on the consumer device, thenotifications can be stored in the notification queue or databaselocally on the consumer device. In some implementations, notificationsthat are delivered to the consumer device can be stored in anotification database along with a record associated with thenotification. In some implementations, the notifications can be pushnotifications.

In some implementations, the notification manager can deliver thenotification to the consumer device where the notification is held by anotification delivery application executing on the consumer device. Insome such implementations, the notification manager can deliver thenotification without determining if the conditions of the consumernotification policy have been met. In some implementations, thenotification delivery application can hold the notifications anddetermine if the conditions of the consumer notification policy havebeen met. In some implementations, the notification delivery applicationcan store the notifications on the consumer device until thenotifications are delivered. In some implementations, the notificationsstored on the consumer device may only be stored for a predeterminedperiod of time. If the notifications are not delivered before thepredetermined period of time lapses, the notifications can be removedfrom storage and the delivery notification application can notify theapplication provider proxy that the notification was not successfullypresented.

The notification manager can identify a consumer notification policy ofthe consumer device applicable to the notification (step 465). Theconsumer notification policy can specify one or more conditions forpresenting the notification at the consumer device. In someimplementations, the notification manager can identify the consumernotification policy of the consumer device applicable to thenotification by inspecting the request to deliver the notification andidentifying a consumer device to which to deliver the notification. Upondetermining the identity of the consumer device, the notification mangercan determine if the consumer device has an associated consumernotification policy. In some implementations, the consumer device canestablish a consumer notification policy via the notification deliveryapplication executing on the consumer device or by communicating withthe notification manager. In some implementations, the notificationmanager can store the consumer notification policy in a data store. Insome implementations, the notification manager can store the consumernotification policy in such a way so as to be able to perform a lookupto determine if the consumer device has an associated consumernotification policy. In some implementations, the consumer notificationpolicies of multiple consumer devices are stored in a databaseaccessible by the notification manager.

In some implementations, the consumer notification policy can bespecific to a particular client. In some implementations, the consumernotification policy can be specific to a particular geographic location,time of day, or mode in which the consumer device is operating. In someimplementations, the consumer notification policy can specify one ormore conditions for presenting the notification at the consumer device.These conditions may be specific to a particular client, type ofnotification, time of day, date, geographic location of the consumerdevice, or other events or conditions that can be identified, detectedor otherwise receivable by the notification manager.

In some implementations, the notification manager can receive a requestfrom the client to deliver a notification to the consumer device andupon receiving the request, the notification manager can identify aconsumer notification policy associated with the consumer device that isapplicable to the notification being delivered. In some implementations,the notification manager can identify the one or more consumer devicesto which the notification is to be delivered and perform a lookup toidentify one or more consumer notification policies associated with theconsumer devices. The notification manager can perform a lookup in aconsumer notification policy database to identify the consumernotification policies. Upon identifying the consumer notificationpolicies, the notification manager can determine which of the one ormore identified consumer notification policies may be applicable. Thenotification manager can determine a consumer notification policy thatmay be applicable based on the type of notification to be delivered.Following the example described above, the notification manager canidentify a consumer notification policy associated with the consumerdevice of the consumer having a low account balance by performing alookup. In some implementations, the notification manager may determinea consumer notification policy based on the type of notification to bedelivered. In some implementations, the consumer notification policy mayinclude one or more rules identifying a delivery channel through whichto deliver the notification, one or more conditions in which to hold thenotification, one or more conditions in which to release thenotification for presentation, or the manner in which the notificationis to be presented on the consumer device. In some implementations, theconditions can be based on a location of the consumer device, activityperformed on the consumer device, or a time associated with the consumerdevice. In some implementations, the consumer notification policy caninclude one or more rules identifying a time at which to deliver thecommunication, such as a push notification, identifying one or moreconditions for delivering the communication, for example, a conditionrequiring that the consumer device be located within a particulargeographic region, amongst other conditions or rules.

In some implementations, the notification can be a push notification tobe delivered to the notification delivery application installed on theconsumer device. The notification manager can identify the conditionsassociated with the consumer notification policy and determine if theconditions have been met. This can include receiving information fromone or more services, including third-party services, or monitoring oneor more other sources of information. In some implementations, theconditions can be based on the consumer device. In some suchimplementations, the notification manager can receive informationrelated to the consumer device via the notification delivery applicationinstalled on the consumer device or via third-party sources monitoringthe consumer device. Examples of information used to determine if theconditions have been met include geographic location of the consumerdevice, time at the location of the consumer device, weather at thelocation of the consumer device, account related information associatedwith the consumer at one or more clients, stock prices, news alerts,commodity prices, or any other information that can be received by theconsumer device.

In some implementations in which the notification manager delivers thenotification to the notification delivery application where thenotifications are held until conditions of the consumer notificationpolicy have been met, the notification delivery application candetermine if the conditions of the consumer notification policy havebeen met. In some implementations, the notification delivery applicationcan determine that the conditions of the consumer notification policyhave been met by performing some of the functionality that thenotification manager performs when determining if the conditions of theconsumer notification policy have been met. In some implementations, thenotification delivery application can determine that the conditions ofthe consumer notification policy have been met by receiving one or moreinstructions from the notification manager indicating that theconditions of the consumer notification policy have been met. In someimplementations, the notification manager can determine that theconditions of the consumer notification policy have been met by firstidentifying one or more conditions of the consumer notification policyand then determining, for at least one of the conditions, that thecondition is based on a triggering event. The notification manager canthen receive information associated with the triggering event anddetermine, from the received information, that the triggering event hasoccurred. For instance, if the triggering event to provide thenotification according to the consumer notification policy is when astock price of the stock goes below $50, the notification manager mayreceive information from a third-party stock information contentprovider that the stock price went below $50.

In some implementations, the notification manager releases, by thenotification manager, from the notification queue, the notification forpresentation at the consumer device upon determining that the conditionsof the consumer notification policy have been met (step 470). In someimplementations, the notification can be a push notification releasedfor presentation at the consumer device via the notification deliveryapplication. In some implementations, the notification manager candetermine that the rules of the consumer notification policy have beenmet. In some implementations, the notification manager can deliver thenotification to the notification delivery application executing on theconsumer device, where the notification delivery application can presentthe notification in accordance with the notification presentation rulesspecified in the consumer notification policy. In some implementations,the notification can be presented in accordance with the delivery policyspecified by the client associated with the notification to bedelivered. As described above, the notification can be deliveredresponsive to receiving a request from the client. In some suchimplementations, the delivery policy of the client can include one ormore conditions according to which notification are to be delivered andpresented.

Following the example described above, once the rules of the consumernotification policy have been met, the application provider proxy canrelease the push notification for presentation at the consumer device.The consumer device can receive the push notification from thenotification manager via a push notification server. In someimplementations, the push notification can be held at the notificationdelivery application. In some such implementations, the pushnotification can be presented once the rules of the consumernotification policy have been met. Upon presenting the pushnotification, the consumer can access the push notification. In someimplementations, responsive to the consumer accessing the pushnotification, the notification delivery application can send a requestto the application provider proxy for additional instructionscorresponding to the push notification. In turn, the applicationprovider proxy can identify the consumer device requesting informationand determine that the consumer associated with the push notificationhas a low account balance. In some implementations, the notificationmanager can then send additional instructions to the notificationdelivery application of the consumer device instructing the notificationdelivery application to launch a mobile application of the client, whichwill show the current account balance of the consumer. In some otherimplementations, the notification manager can send instructions toperform one or more other actions, such as launching a web browser,amongst others.

Through the teachings disclosed herein, clients can deliver messages toone or more consumers across multiple delivery channels by establishingan SMPP connection with the message delivery system and sending an SMPPrequest that includes a message and a delivery policy providinginstructions for delivering the message to the one or more consumers.

While the invention has been particularly shown and described withreference to specific embodiments, it should be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the inventiondescribed in this disclosure.

While this specification contains many specific embodiment details,these should not be construed as limitations on the scope of anyinventions or of what may be claimed, but rather as descriptions offeatures specific to particular embodiments of particular inventions.Certain features described in this specification in the context ofseparate embodiments can also be implemented in combination in a singleembodiment. Conversely, various features described in the context of asingle embodiment can also be implemented in multiple embodimentsseparately or in any suitable subcombination. Moreover, althoughfeatures may be described above as acting in certain combinations andeven initially claimed as such, one or more features from a claimedcombination can in some cases be excised from the combination, and theclaimed combination may be directed to a subcombination or variation ofa subcombination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the embodiments described above should not be understoodas requiring such separation in all embodiments, and it should beunderstood that the described program components and systems cangenerally be integrated in a single software product or packaged intomultiple software products.

References to “or” may be construed as inclusive so that any termsdescribed using “or” may indicate any of a single, more than one, andall of the described terms.

Thus, particular embodiments of the subject matter have been described.Other embodiments are within the scope of the following claims. In somecases, the actions recited in the claims can be performed in a differentorder and still achieve desirable results. In addition, the processesdepicted in the accompanying figures do not necessarily require theparticular order shown, or sequential order, to achieve desirableresults. In certain embodiments, multitasking and parallel processingmay be advantageous.

What is claimed is:
 1. A method for delivering and presenting notifications at a consumer device, comprising: receiving, by a notification manager, from a client device, a notification to be delivered to an application executing on a consumer device; holding, by the notification manager, the notification in a notification queue; identifying, by the notification manager, a consumer notification policy of the consumer device applicable to the notification, the consumer notification policy specifying one or more conditions for presenting the notification at the consumer device; and releasing, by the notification manager, from the notification queue, the notification for presentation at the consumer device upon determining that the conditions of the consumer notification policy have been met.
 2. The method of claim 1, wherein the notification manager is configured on a device intermediary to the client device and a plurality of consumer devices including the consumer device.
 3. The method of claim 1, wherein the notification manager is configured on the consumer device.
 4. The method of claim 1, further comprising determining that the conditions of the consumer notification policy have been met, wherein determining that the conditions of the consumer notification policy have been met includes: identifying one or more conditions of the consumer notification policy; determining, for at least one of the conditions, that the condition is based on a triggering event; receiving, by the notification manager, information associated with the triggering event; and determining, from the received information, that the triggering event has occurred.
 5. The method of claim 1, wherein identifying a consumer notification policy associated with the consumer device applicable to the notification to be delivered includes determining a consumer notification policy based on the type of notification to be delivered.
 6. The method of claim 1, wherein the consumer notification policy includes rules identifying a) a delivery channel through which to deliver the notification, b) one or more conditions in which to hold the notification, c) one or more conditions in which to release the notification for presentation, or d) the manner in which the notification is to be presented on the consumer device.
 7. The method of claim 1, wherein one or more of the conditions are based on a location of the consumer device, activity performed on the consumer device, or a time associated with the consumer device.
 8. The method of claim 1, wherein holding the notification until conditions of the consumer notification policy have been met includes: receiving third-party data from a third-party source corresponding to the one or more conditions of the consumer notification policy; and determining, based on the received third-party data, that conditions of the consumer notification policy have been met.
 9. The method of claim 1, wherein holding the notification until conditions of the consumer notification policy have been met includes storing the notification in a notification database along with a record associated with the notification.
 10. The method of claim 1, wherein releasing the notification for presentation at the consumer device upon determining that the conditions of the consumer notification policy have been met includes delivering, by the notification manager, the notification to a notification delivery application executing on the consumer device, where the notification delivery application presents the notification in accordance with notification presentation rules specified in the consumer notification policy.
 11. A system for delivering and presenting notifications at a consumer device, the system comprising: a delivery manager intermediary to a client device and a consumer device and configured to: receive, from a client device, a notification to be delivered to an application executing on a consumer device; hold the notification in a notification queue; identify a consumer notification policy of the consumer device applicable to the notification, the consumer notification policy specifying one or more conditions for presenting the notification at the consumer device; and release, from the notification queue, the notification for presentation at the consumer device upon determining that the conditions of the consumer notification policy have been met.
 12. The system of claim 11, wherein the notification manager is further configured on a device intermediary to the client device and a plurality of consumer devices including the consumer device.
 13. The system of claim 11, wherein the notification manager is further configured on the consumer device.
 14. The system of claim 11, wherein the delivery manager is further configured to determine that the conditions of the consumer notification policy have been met, and wherein to determine that the conditions of the consumer notification policy have been met, the delivery manager is further configured to: identify one or more conditions of the consumer notification policy; determine, for at least one of the conditions, that the condition is based on a triggering event; receive information associated with the triggering event; and determine, from the received information, that the triggering event has occurred.
 15. The system of claim 11, wherein to identify the consumer notification policy associated with the consumer device applicable to the notification to be delivered, the processor is further configured to determine a consumer notification policy based on the type of notification to be delivered.
 16. The system of claim 11, wherein the consumer notification policy includes rules identifying a) a delivery channel through which to deliver the notification, b) one or more conditions in which to hold the notification, c) one or more conditions in which to release the notification for presentation, or d) the manner in which the notification is to be presented on the consumer device.
 17. The system of claim 11, wherein one or more of the conditions are based on a location of the consumer device, activity performed on the consumer device, or a time associated with the consumer device.
 18. The system of claim 11, wherein to hold the notification until conditions of the consumer notification policy have been met, the processor is configured to: receive third-party data from a third-party source corresponding to the one or more conditions of the consumer notification policy; and determine, based on the received third-party data, that conditions of the consumer notification policy have been met.
 19. The system of claim 11, wherein to hold the notification until conditions of the consumer notification policy have been met, the processor is further configured to store the notification in a notification database along with a record associated with the notification.
 20. The system of claim 11, wherein to release the notification for presentation at the consumer device upon determining that the conditions of the consumer notification policy have been met, the delivery manager is further configured to deliver the notification to a notification delivery application executing on the consumer device, where the notification delivery application presents the notification in accordance with notification presentation rules specified in the consumer notification policy. 